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About  This  Guide 


Software  process  improvement  (SPI)  is  a  challenging  un¬ 
dertaking  for  any  organization.  We  hope  that  the  guide¬ 
lines  given  in  this  doctnnent  will  help  those  undertaking  a 
SPI  initiative  for  the  first  time  and  also  those  who  are  con¬ 
tinuing  an  existing  SPI  initiative. 

Organization  of  We  describe  the  major  activities  of  software  process  im- 
the  Guide  provement  relative  to  the  five  phases  of  the  IDEAL^mI  mod¬ 

el  in  Chapters  1.0  through  5.0.  Chapter  6.0  provides  guid¬ 
ance  for  developing  a  software  process  improvement  infra¬ 
structure  and  also  describes  the  roles  and  responsibilities 
of  that  infrastructure.  The  format  of  Chapter  6.0  (Manage 
the  Software  Process  Improvement  Program)  is  different 
from  the  other  chapters  because  the  management  and  in¬ 
frastructure  activities  discussed  there  are  continuous  and 
and  not  part  of  the  IDEAL  model  phases.  In  general,  we 
limit  the  chapter  structure  to  three  levels  of  detail.  Where 
additional  detail  is  needed  it  is  provided  in  the  appendices: 

•  Appendix  A.O,  Components  of  the  Software  Process  Im¬ 
provement  Infrastructure. 

•  Appendix  B.O,  Charters  and  Templates. 

•  Appendix  C.O,  Establish  Organization  Process  Maturity 
Baseline. 

Following  these  appendices,  we  provide  a  glossary 
(page  215).  When  we  introduce  a  new  term  or  key  phrase  in 
the  text  for  the  first  time,  we  print  the  term  or  phrase  in 


IDEAL  is  a  service  mark  of  Carnegie  Mellon  University. 
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bold  typeface  to  indicate  that  it  is  defined  in  the  glossary. 
There  is  also  an  index  on  page  219. 

Objectives  The  objective  of  this  document  is  to  communicate  a  path  of 

actions  that  constitute  a  SPI  initiative,  based  on  the  expe¬ 
riences  the  Software  Engineering  Institute  (SEI)  has 
gained  while  working  with  its  respective  government  and 
industry  clients.  We  expect  that  an  organization  will  tailor 
the  steps  outlined  in  this  document  to  fit  its  resources,  vi¬ 
sion  and  business  objectives. 

The  guide  is  also  based  on  the  work  of  several  projects  at 
the  SEI.  SEI  projects  whose  work  contributed  directly  or  in¬ 
directly  to  the  material  in  this  guide  include  the  following:^ 
Capability  Maturity  Model,  Software  Process  Assessment, 
Software  Capability  Evaluation,  Organization  Capability 
Development,  Software  Process  Measurement,  and  Soft¬ 
ware  Process  Definition. 

Acknowlodgments  IDEAL:  A  User’s  Guide  for  Software  Process  Improvement 
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the  IDEAL  model  to  software  process  improvement  practic¬ 
es  and  the  lessons  learned  fi*om  these  experiences.  Con¬ 
cepts  in  the  guide  were  proven  with  the  SEI  client  base 
within  the  Department  of  Defense  and  internal  software 
process  improvement  activities  at  Hewlett-Packard. 
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the  many  people  without  whom  this  guide  would  not  have 
been  possible. 

Thanks  go  to  Bill  Peterson,  Steve  Masters,  and  Donna 
Dunaway  for  their  helpful  comments  and  suggestions. 


The  names  given  here  reflect  the  names  of  the  projects  at  the  time  the  work  was  done.  Names  have 
changed  since  then. 

2-  McFeeley,  Robert  S.;  McKeehan,  David  W.;  &  Temple,  Timothy.  Software  Process  Improvement  Road¬ 
map  (SEI-94-SR-2)  is  a  limited  distribution  document  not  approved  for  public  release. 
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For  a  list  of  the  important  published  findings  in  the  field  of 
software  process  improvement,  please  refer  to  the  SEI  An¬ 
notated  Listing  of  Documents 

The  guide  was  edited,  formatted,  and  indexed  by  Bob  Lang 
at  the  SEI. 
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Improving  the 
Guide 


We  would  appreciate  any  suggestions  you  may  have  for 
how  this  document  could  be  improved.  Send  comments  to 

Bob  Lang 

Software  Engineering  Institute 
Carnegie  Mellon  University 
Pittsburgh,  PA  15213-3890 
Internet:  ijl@sei.cmu.edu 
FAX:  (412)  268-5758 
Phone:  (412)  268-3156 
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6510.  FAX:  (412)  321-2994 
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Introduction 


Overview  This  document  describes  a  software  process  improvement 

(SPI)  program  model,  IDEAL,  which  can  be  used  to  guide 
development  of  a  long-range,  integrated  plan  for  initiating 
and  managing  a  SPI  program.  The  purpose  of  this  docu¬ 
ment  is  to  provide  process  improvement  managers  with  a 
generic  description  of  a  sequence  of  recommended  steps  for 
SPI. 

IDEAL  Model  The  model  shown  in  Figure  Intro-1  on  page  2  depicts  five 

phases  of  a  SPI  initiative,  which  provide  a  continuous  loop 
through  the  steps  necessary  for  SPI.  It  is  important  to  note 
that  the  length  of  time  it  takes  to  complete  a  cycle  through 
the  IDEAL  model  will  vary  from  organization  to  organiza¬ 
tion.  Organizations  will  find,  depending  on  the  resources 
they  are  able  to  commit  to  the  SPI  program,  many  activities 
that  can  be  pursued  in  a  parallel  fashion.  There  will  also  be 
instances  of  some  parts  of  the  organization  pursuing  activ¬ 
ities  in  one  phase  of  the  model  while  others  are  pursuing 
activities  in  a  different  phase.  In  practice  the  boundaries 
between  the  phases  of  IDEAL  are  not  as  clearly  defined  as 
shown  in  the  model. 

It  is  also  important  to  note  that  the  infi'astructure  set  up  to 
accomplish  SPI  will  play  a  significant  role  in  the  success  or 
failm-e  of  a  SPI  initiative.  The  value  that  the  infrastructure 
brings  to  a  SPI  initiative,  its  understanding  of  its  roles  and 
responsibilities,  cannot  be  underestimated. 
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Figure  lntro-1:  The  IDEAL  Model 

Initiating  Phase  The  Initiating  phase  of  the  IDEAL  model  is  the  starting 

point.  Here  is  where  the  initial  improvement  infrastruc¬ 
ture  is  established,  the  roles  and  responsibilities  for  the  in¬ 
frastructure  are  initially  defined,  and  initial  resources  are 
assigned.  In  this  phase,  a  SPI  plan  is  created  to  guide  the 
organization  through  the  completion  of  the  Initiating,  Di¬ 
agnosing  and  Establishing  phases.  Approval  for  the  SPI 
initiative  is  obtained  along  with  a  commitment  of  future  re¬ 
sources  for  the  job  ahead. 

The  general  goals  of  the  SPI  program  are  defined  during 
the  Initiating  phase.  They  are  established  from  the  busi¬ 
ness  needs  of  the  organization  and  will  be  refined  and  made 
specific  during  the  Establishing  phase  of  IDEAL. 

The  initial  infrastructure  to  support  and  facilitate  SPI  will 
be  established  during  the  Initiating  phase.  Two  key  compo- 
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Diagnosing  Phase 


Establishing 

Phase 


nents  are  t5rpically  established,  a  management  steering 
group  (MSG)  and  a  software  engineering  process  group 
(SEPG).  Also  during  the  Initiating  phase,  plans  are  made 
for  communicating  the  start  of  the  SPI  initiative,  and  it  is 
suggested  that  organizational  assessments  be  performed  to 
determine  the  readiness  of  the  organization  for  a  SPI  ini¬ 
tiative. 

The  Diagnosing  phase  of  the  IDEAL  model  starts  the  orga¬ 
nization  on  the  path  of  continuous  software  process  im¬ 
provement.  This  phase  lays  the  groundwork  for  the  later 
phases.  In  this  phase,  the  SPI  action  plan  is  initiated  in  ac¬ 
cordance  with  the  organization’s  vision,  strategic  business 
plan,  lessons  learned  from  past  improvement  efforts,  key 
business  issues  faced  by  the  organization,  and  long-range 
goals.  Appraisal  activities  are  performed  to  establish  a 
baseline  of  the  organization’s  current  state.  The  results 
and  recommendations  from  appraisals  emd  any  other  base¬ 
lining  activities  will  be  reconciled  with  existing  and/or 
planned  improvement  efforts  for  inclusion  into  the  SPI  ac¬ 
tion  plan. 

During  the  Establishing  phase,  the  issues  that  the  organi¬ 
zation  has  decided  to  address  with  its  improvement  activi¬ 
ties  are  prioritized;  strategies  for  pursuing  the  solutions 
are  also  developed.  The  SPI  action  plan  draft  will  be  com¬ 
pleted  in  accordance  with  the  organization’s  vision,  strate¬ 
gic  business  plan,  lessons  learned  from  past  improvement 
efforts,  key  business  issues  facing  the  organization  and 
long-range  goals. 

During  the  Establishing  phase,  measurable  goals  are  de¬ 
veloped  from  the  general  goals  that  were  defined  in  the  Ini¬ 
tiating  phase;  these  measurable  goals  will  be  included  in 
the  final  version  of  the  SPI  action  plan. 

Metrics  necessary  to  monitor  progress  are  also  defined,  and 
resources  are  committed  and  training  provided  for  the 
technical  working  groups  (TWGs).  The  action  plan  devel¬ 
oped  will  guide  the  SPI  activity  as  it  addresses  the  priori- 
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Acting  Phase 


Leveraging  Phase 


tized  findings  and  recommendations  from  the  Diagnosing 
phase.  Also  during  this  phase,  tactical  action  plan  tem¬ 
plates  are  created  and  made  available  for  the  TWGs  to  com¬ 
plete  and  follow. 

In  the  Acting  phase  of  the  IDEAL  model,  solutions  to  ad¬ 
dress  the  areas  for  improvement  discovered  during  the  Di¬ 
agnosing  phase  are  created,  piloted,  and  deployed  through¬ 
out  the  organization.  Plans  will  be  developed  to  execute  pi¬ 
lots  to  test  and  evaluate  the  new  or  improved  processes. 
After  successful  piloting  of  the  new  processes  and  deter¬ 
mining  their  readiness  for  organization-wide  adoption,  de¬ 
ployment,  and  institutionalization,  plans  to  accomplish  the 
roll-out  are  then  developed  and  executed. 

The  objective  of  the  Leveraging  phase  is  to  make  the  next 
pass  through  the  IDEAL  model  more  effective.  By  this 
time,  solutions  have  been  developed,  lessons  have  been 
learned,  and  metrics  on  performance  and  goal  achievement 
have  been  collected.  These  artifacts  are  added  to  the  pro¬ 
cess  database  that  will  become  a  source  of  information  for 
personnel  involved  in  the  next  pass  through  the  model. 

Using  this  collected  information,  an  evaluation  of  the  strat¬ 
egy,  methods  and  infrastructure  used  in  the  SPI  program 
can  be  performed.  By  doing  this,  corrections  or  adjustments 
to  the  strategy,  methods,  or  infrastructure  can  be  made  pri¬ 
or  to  the  start. 

Some  questions  that  should  be  asked  include:  Has  the  in¬ 
frastructure  (MSG,  SEPG,  TWGs,  etc.)  performance  been 
appropriate?  Have  the  methods  employed  by  the  TWGs  in 
their  solution  development  activities  been  satisfactory? 
Have  the  SPI  communications  activities  been  sufficient? 
Does  the  sponsorship  for  SPI  need  to  be  reaffirmed?  Does 
another  baselining  activity  need  to  be  performed?  The  re¬ 
entry  point  into  the  IDEAL  model  for  the  next  cycle  is  high¬ 
ly  dependent  on  the  answers  to  questions  such  as  these. 


4 


CMU/SEI-96-HB-001 


Introduction 


Applying  the  When  applying  the  IDEAL  model  it  should  be  remembered 

that  there  are  two  components  to  a  software  process  im¬ 
provement  activity,  a  strategic  component  along  with  a  tac¬ 
tical  component. 

The  strategic  component,  based  on  the  organizations  busi¬ 
ness  needs  and  drivers,  will  provide  guidance  and  prioriti¬ 
zation  of  the  tactical  activities. 

Figure  Intro-2  on  page  5  shows  a  two  dimensional  view  of 
the  application  of  the  IDEAL  model.  This  guide  is  intended 
to  address  these  two  operational  levels  within  a  process  im¬ 
provement  initiative: 

•  A  strategic  level,  in  which  there  are  processes  that  are 
the  responsibility  of  senior  management. 

•  A  tactical  level,  in  which  processes  are  modified,  created 
and  executed  by  line  managers  and  practitioners. 


Strategic 

Level 


♦ 

ComimmicaiimL 


Tacflcal 
Lev# 


6.0;  Manage  the  Software  Process  Improvement  Program 


^2.0:  The  ^ 

r~~ . . . ^ 

3.0:  The 

_______ 

4.0:  The  Acting 

Diagnosing 

Phase 

V  J 

Establishing 

Phase 

\ _ _ / 

— 1 

Phase 

_ J. 

Figure  Intro-2:  Two-Dimensional  View  of  a  Process  Improvement  Activity 


The  flow  depicted  in  Figure  Intro-2  should  be  viewed  as  a 
continuous  flow.  As  improvement  activity  is  completed, 
both  the  strategic-level  and  tactical-level  activities  return 
to  the  Leveraging  phase,  where  management  commitment 
is  reaffirmed,  new  baselines  are  planned,  and  strategy  may 
or  may  not  be  redirected. 
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Structure  of  the  This  document  describes  the  5  phases  of  the  IDEAL  model, 

shown  in  Figure  Intro- 1  on  page  2.  These  phases  of  the 
IDEAL  model  contain  a  set  of  tasks  that  are  executed  dur¬ 
ing  the  implementation  of  a  SPI  program.  A  sixth  activity, 
that  of  providing  management  oversight  to  the  program,  is 
described  in  the  final  chapter  of  this  guide.  Descriptions  of 
these  activities  make  up  the  remaining  six  chapters  of  this 
guide.  The  IDEAL  phases  in  Figure  Intro- 1  match  the 
chapters  within  the  document. 

The  activities  in  the  guide  are  listed  and  briefly  summa¬ 
rized  in  the  following  table: 


Activity  Name 

Activity  Purpose 

See 

Page 

1.0:  The  Initiating  Phase 

i 

j 

Learn  about  process  improvement, 

commit  initial  resources,  and  build 
process  infrastructure. 

11 

2.0:  The  Diagnosing  Phase 

_ _ _ _ 

Establish  current  levels  of  process 
maturity,  process  descriptions, 
metrics,  etc.  Initiate  action  plan 
development. 

53 

!  3.0:  The  Establishing  Phase 

Establish  goals  and  priorities,  complete 
action  plan. 

67 

^4.0:  The  Acting  Phase 

I 

i 

I - 

Research  and  develop  solutions  to 
process  problems.  Expand 
successful  process  improvements 
to  entire  organization. 

93 

5.0:  The  Leveraging  Phase 

i 

i 

Prepare  for  the  next  cycle  through  the 
IDEAL  model.  Apply  the  lessons 
learned  to  refine  the  SPI  process. 

127 

6.0:  Manage  the  Software  Process 
Improvement  Program 

Provide  oversight  to  the  improvement 
projects  and  resolve  issues. 

141 

In  general,  the  chapter  structure  has  been  limited  to  three 
levels  of  detail.  Additional  detail  is  provided  in  the  appen¬ 
dices. 
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The  guide  is  intended  to  be  general  and  does  not  presup¬ 
pose  or  force  any  particular  methodology.  For  a  list  of 
sources  that  can  be  used  to  support  and  help  ensure  a  suc¬ 
cessful  SPI  program,  see  the  Software  Engineering  Insti¬ 
tute  Annotated  Listing  of  Documents?' 

Purpose  This  document  is  intended  to  provide  an  organization  with 

a  guide  to  establishing  and  carrying  out  a  SPI  program.  It 
is  written  primarily  from  the  point  of  view  of  the  organiza¬ 
tion  setting  up  the  program,  not  from  an  external  consult¬ 
ant’s  or  solution  provider’s  point  of  view.  The  expected  us¬ 
ers  are  the  champions  of  SPI,  mainly  SPI  program  manag¬ 
ers.  Other  users  who  would  benefit  from  review  of  the 
document  include  senior  managers,  line  managers,  and  in¬ 
dividuals  who  are  interested  and/or  have  a  stake  in  improv¬ 
ing  the  software  development  capability  of  the  organiza¬ 
tion. 


Some  Assembly 
Required:  One 
Size  Does  Not  Fit 
All! 


This  guide  is  organized  in  a  best-case  scenario.  There  will 
always  be  real-world  events  that  prevent  organizations 
from  following  a  set  sequence  in  process  improvement.  SPI 
managers  must  tailor  the  guide  to  their  particular  situa¬ 
tion.  The  sequence  presented  here  is  recommended  because 
as  baselines  are  completed,  the  SPI  managers  and  practi¬ 
tioners  will  come  under  increasing  pressure  to  produce 
plans,  actions  and  results.  Because  it  will  be  difficult  to  al¬ 
locate  time  for  organizing  and  planning  later  in  the  pro¬ 
cess,  managers  must  make  sure  that  time  is  allocated  up 
front  to  accomplish  these  activities.  Clear  tmderstanding  of 
what  will  be  done,  why,  by  whom,  and  when  it  will  be  done 
will  be  invaluable  for  maintaining  the  momentum  of  a  SPI 
program. 


This  guide  recommends  that  1-3%  of  an  organization’s  per¬ 
sonnel  be  applied  to  managing  and  executing  SPI.  Given 
these  recommendations,  the  guide  is  intended  to  be  used  by 
organizations  that  are  large  enough  to  assign  at  least  one 


1 .  Available  from  Research  Access,  Inc.,  800  Vinial  Street,  Pittsburgh,  PA  15212. 
Phone:  1-800-685-6510.  FAX:  (412)  321-2994 
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Organization  vs. 

Corporate 

Considerations 


full-time  and  one  part-time  person  to  SPI.  At  least  two  peo¬ 
ple  are  needed  to  provide  synergy  and  backup  in  activities. 
Smaller  organizations,  those  with  30  to  50  people  or  so,  will 
require  a  strong  commitment  to  sustain  a  SPI  effort.  Orga¬ 
nizations  of  this  size  have  successfully  conducted  SPI  pro¬ 
grams.  Scale  issues  need  to  be  addressed  for  organizations 
of  this  size,  as  they  are  probably  not  complex  enough  to 
warrant  the  typical  SPI  infrastructure.  Regardless  of  size, 
it  is  recommended  that  at  least  one  person  be  applied  full 
time  to  facilitate  and  execute  SPI. 

On  the  other  hand,  process  groups  in  large  organizations 
can  become  too  bureaucratic  and  could  lose  contact  with 
the  technical  staffs  they  are  designed  to  help.  Large  orga¬ 
nizations  (more  than  600  people)  should  consider  dividing 
process  groups  into  the  corporate  organizational  model  de¬ 
scribed  in  6.2:  Organizing  the  SPI  Program  beginning  on 
page  146. 

This  guide  is  primarily  focused  on  organization-specific  ac¬ 
tivities.  To  be  successful,  such  activities  do  not  require  a 
corporate  program.  A  corporate  program  cannot  fulfill  all 
(or  many)  of  the  functions  of  an  organization  program: 

•  It  is  too  far  away. 

•  There  is  too  much  “normalization.”  That  is,  the 
organization  subcultures  are  too  different  for  a  single 
set  of  practices  and  solutions. 

•  There  are  never  enough  resources  (resources  would  be 
spread  too  thin). 

However,  a  corporate  program  can  be  beneficial  in  some  ar¬ 
eas;  the  guide  does  include  those  activities  for  which  a  cor¬ 
porate  office  would  be  responsible.  Within  a  corporation 
that  is  made  up  of  a  number  of  separate  organizations, 
there  may  and  probably  will  exist  a  hierarchy  of  SPI  pro¬ 
grams.  The  corporate  program  would  perform  activities  in 
its  corporate  context,  including 
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SPI  Plan 


SPI  Action  Plan 


•  Establishing  infrastructure  and  links  to  support  and 
coordinate  the  organization  programs. 

•  Looking  outside  the  corporation  for  “process  reuse.” 

•  Supporting  organizational  activities  through  resources, 
common  practices,  communication,  etc. 

•  Spreading  findings,  practices,  information,  etc. ,  across  a 
wider  base  within  the  corporation. 

•  Acting  as  a  focal  point  for  outside  process  improvement 
influences,  such  as  those  from  the  SEI,  ISO  9000,  etc. 

Within  this  guide  there  is  some  discussion  around  the 
plans  that  are  developed  to  guide  and  provide  focus  to  the 
SPI  program.  This  guide  refers  to  some  of  the  different 
types  of  plans  that  can  be  used  during  the  SPI  initiative. 
Depending  on  the  size,  culture  and  structure  of  an  organi¬ 
zation  it  may  require  more,  or  possibly  fewer,  plans  to  pro¬ 
vide  the  SPI  guidance  required. 

This  plan  is  a  high  level  plan  with  broad  goals  that  outlines 
the  SPI  initiative  that  the  organization  will  be  following. 
Creation  of  this  plan  is  started  in  the  early  part  of  the  Ini¬ 
tiating  phase  of  the  IDEAL  model  and  carries  the  organiza¬ 
tion  through  the  completion  of  the  baselining  activities  in 
the  Diagnosing  phase. 

Responsibility  for  developing  this  plan  is  shared  among  the 
discovery  team,  the  management  steering  group  and  the 
software  engineering  process  group.  Senior  management 
will  have  approval  responsibility  for  this  plan. 

This  plan  is  created  from  input  obtained  from  the  baselin¬ 
ing  activities  that  take  place  during  the  Establishing 
phase.  Information  gained  from  the  baselining  activities, 
combined  with  input  from  the  organizations  vision  and 
business  needs  are  used  to  create  the  action  plan  that  will 
guide  the  SPI  effort  for  the  next  few  years. 

The  SPI  action  plan  contains  the  areas  of  improvement 
that  will  be  addressed  during  the  SPI  activity,  their  rela- 
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Pilot  Plans 


Deployment  or 
Rollout  Plans 


Communications 

Plans 


tive  priorities,  and  a  description  of  the  process  that  will  be 
followed  to  accomplish  the  improvement.  This  action  plan 
is  usually  developed  by  the  MSG  with  input  and  help  from 
the  SEPG. 

These  plans  will  provide  guidance  to  the  TWGs  that  are 
formed  to  address  a  specific  improvement  activity  from  the 
SPI  action  plan.  Usually  there  is  a  template  of  the  format 
for  this  plan,  partially  completed  by  the  SEPG  and  given  to 
the  TWG  at  its  start  up.  The  TWG  will  then  complete  the 
remainder  of  the  template  and  submit  the  completed  plan 
to  the  MSG  for  approval. 

Pilot  plans  are  generated  from  an  existing  template  sup¬ 
plied  to  the  TWG  by  the  SEPG.  It  is  a  plan  that  is  used  to 
guide  the  first  installation  of  a  potential  solution  to  one  of 
the  findings  fi-om  the  baselining  activities.  This  plan  is 
completed  in  conjunction  with  the  organization  component 
that  has  agreed  to  pilot  the  solution.  It  is  approved  by  the 
management  of  the  organization  that  is  to  receive  the  pilot 
installation. 

This  plan  is  developed  after  successful  installation  of  the 
pilot  solution,  appl5dng  any  lessons  learned  from  the  pilot 
activity.  It  is  used  to  guide  the  deplo5rment  of  the  solution 
organization  wide.  It  is  approved  by  the  MSG. 

These  plans  are  developed  and  updated  throughout  the  SPI 
activity  to  keep  the  organization  informed  of  the  SPI  activ¬ 
ities.  Keeping  the  organization  aware  of  what  is  happening 
will  contribute  to  achieving  buy  in  and  sponsorship  for  the 
SPI  program. 
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1 .0  The  Initiating  Phase 


Overview  This  is  the  initial  step  in  the  IDEAL  model.  In  this  phase, 

the  organization’s  senior  management  first  understands 
the  need  software  process  improvement  (SPI),  commits  to 
a  SPI  program,  and  defines  the  context  for  SPI. 

This  step  is  similar  to  the  definition  of  a  new  system.  An 
initial  high  level  SPI  plan  and  schedule  for  initial  SPI  tasks 
are  developed,  major  functional  elements  defined,  and  key 
interfaces  and  requirements  are  also  defined  and  agreed 
upon.  This  high  level  plan  will  guide  the  organization 
through  completion  of  the  Establishing  phase,  at  which 
time  a  SPI  action  plan  will  be  completed.  Typically  a  dis¬ 
covery  team  will  be  formed  to  explore  the  issues  and  to  de¬ 
velop  a  SPI  proposal  to  senior  management.  Following  the 
approval  of  the  SPI  proposal,  the  infi'astructure  for  launch¬ 
ing  the  SPI  program  will  be  formed. 

The  organization  needs  to  decide  how  it  will  organize  its 
improvement  efforts,  who  will  be  involved,  both  at  the 
practitioner  and  management  levels,  and  how  much  of 
those  people’s  time  will  be  allocated  to  the  effort.  Based  on 
these  initial  decisions,  the  charter  and  staffing  for  the  man¬ 
agement  steering  group  (MSG),  software  engineering 
process  group  (SEPG),  and  other  organizational  entities 
can  be  completed.  These  entities  then  develop  working  pro¬ 
cedures,  plans,  and  schedules  to  steer  the  organization 
through  the  process  improvement  program.  Appendix  A.O 
on  page  167  further  defines  the  organizational  infrastruc¬ 
ture  for  SPI. 

Planning  is  very  important  in  this  step.  Once  the  baselin¬ 
ing  efforts  (in  the  Diagnosing  phase)  are  under  way,  the 
MSG  and  SEPG  will  come  under  increasing  pressure  to 
produce.  It  is  usually  very  difficult  to  allocate  enough  time 
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Education/Skills 


at  that  point  to  organizing  the  effort.  A  clear  understanding 
by  both  the  MSG  and  the  SEPG  of  what  will  be  done,  how, 
and  when,  before  the  baselining  activities,  is  essential  for 
setting  the  stage  for  effective  work  afterwards. 


•  Recognize  and  understand  the  stimulus  for  improve¬ 
ment. 

•  Set  context  and  establish  sponsorship  for  the  SPI  pro¬ 
gram. 

•  Launch  the  SPI  program  by  building  an  understanding 
and  an  awareness  of  the  costs  and  benefits. 

•  Commit  the  resources  necessary. 

•  Establish  the  initial  infrastructure  needed  to  imple¬ 
ment  and  manage  the  program. 

•  Bmld  initial  awareness,  skills,  and  knowledge  to  start 
SPI. 

•  Gain  an  understanding  of  what  commitment  is  neces¬ 
sary  for  successful  SPI. 

•  Determine  readiness  to  proceed. 

•  Create  a  proposal  for  a  SPI  program,  outlining  the 
needs  for  SPI,  the  scope  of  the  program,  and  resource  re¬ 
quirements. 

•  Recommend  a  schedule  and  inffastructirre  to  manage 
the  program. 

•  Plan  for  and  commit  to  the  next  steps. 


Training  and  skill  development  for  the  Initiating  phase  is 
shown  in  the  following  table. 

Because  the  organization  is  probably  just  starting  to  learn 
about  SPI  and  how  to  go  about  launching  a  SPI  program, 
this  step  requires  substantial  education  and  training.  The 


table  below  shows  the  breakdown  of  education  and  training 
needs. 
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Education/Skills 

MSG 

SEPG 

Discovery 

Team 

Line 

Managers 

Practitioners 

;  Planning 

j - — _ _ 

X 

X 

X 

Team  Development 

I - — - 

X 

I 

Managing  Technological 
Change 

- - - 

X 

X 

X 

- j 

SPI  Benefits 

X 

X 

X 

X 

X  j 

Vision  setting 

X 

X 

X 

X 

j 

;  Consulting  skills 

X 

I 

I  for  software 

I - - - 

X 

X 

X 

X 

X 

SPI  processes 

X 

X 

X 

^  CMM  is  a  service  mark  of  Carnegie  Mellon  University. 


Commitment  Commitment  and  sponsorship  are  key.  Without  strong,  in¬ 

formed,  and  steadfast  commitment  and  sponsorship  from 
senior  management,  the  effort  is  doomed  from  the  start.  If 
the  champion  cannot  obtain  the  level  of  commitment  and 
sponsorship  described  in  this  guide,  the  effort  is  better  de¬ 
ferred  until  the  commitment  and  sponsorship  are  present. 

Senior  management’s  initial  commitment  is  to 

•  allow  the  discovery  team  to  form  and  to  explore  the 
issues  and  develop  a  SPI  proposal 

•  provide  the  discovery  team  with  the  business  need  for 
process  improvement. 

•  provide  the  discovery  team  with  the  resources  neces¬ 
sary  to  develop  the  proposal 

This  is  followed  by  committing  to  implement  the  SPI  pro¬ 
posal  and  backed  up  by  assigning  resources  to  the  SEPG 
and  creating  and  resourcing  other  necessary  SPI  infra¬ 
structure  elements. 
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Communication 


The  line  management  stakeholders  also  must 

•  commit  time  and  effort  to  participate  in  SPI 

•  form  and  commit  time  to  the  MSG 

•  form  and  commit  resources  to  the  SEPG 

•  plan  to  manage  the  SPI  program  and  develop  a  strategy 
in  the  steps  that  follow 

•  commit  time  for  practitioners  to  participate  on 

technical  working  groups  (TWGs) 

Prospective  SEPG  members  also  must  commit  time  to  work 
on  the  SEPG  and  understand  that  this  commitment  could 
result  in  a  substantial  change  in  their  work  assignments 
within  the  organization. 

The  discovery  team  will  regularly  communicate  the  results 
of  its  work  to  the  entire  organization  and  to  key  organiza¬ 
tion  stakeholders  and  senior  management  in  particular. 
These  communications  take  the  form  of  general  informa¬ 
tion  exchanges  about  what  the  team  is  learning  and  what 
is  happening,  along  with  specific  requests  for  decisions  and 
commitment  from  senior  management. 

Senior  management  must  communicate  the  business  objec¬ 
tives,  goals,  and  rationale  for  the  SPI  program,  and  the  ur¬ 
gency  of  those  efforts.  They  must  show  to  the  organization 
active  commitment  to  the  effort. 

Once  the  infrastructure  is  formed,  the  MSG  and  SEPG 
must  maintain  a  steady  flow  of  communication  throughout 
the  organization  about  what  is  happening. 

In  the  absence  of  any  specific  information,  people  tend  to 
assume  the  worst.  A  change  effort  of  this  magnitude  causes 
substantial  fear  and  uncertainty  throughout  the  organiza¬ 
tion;  resistance  to  change  will  show  up  for  a  variety  of  rea¬ 
sons.  Regular  and  effective  communications  will  alleviate 
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Entry  Criteria 


Exit  Criteria 


some  of  that  concern.  Developing  and  following  a  communi¬ 
cations  plan  will  pay  dividends. 

Organizations  may  initiate  a  SPI  program  because  of  some 
disaster  or  impending  disaster  in  their  business  that  in¬ 
cludes  their  software  capabilities,  or  through  a  desire  to 
maintain  or  improve  their  competitive  edge  through  the 
quality  and  productivity  of  their  software  processes.  Usual¬ 
ly  there  are  one  or  more  champions  of  SPI  who  lobby  to  get 
an  effort  started  and  investigate  ways  to  launch  a  program. 

The  key  entry  criteria  are 

•  Critical  business  needs  to  improve  software  develop¬ 
ment  processes  exist  and  are  fully  understood. 

•  Organization  champion(s)  for  SPI  are  identified. 

Experience  has  shown  that  there  are  some  key  factors  that 
will  enhance  the  chances  for  a  successful  SPI  program. 
Having  the  correct  levels  of  sponsorship  for  the  program, 
developing  an  infrastructure  staffed  with  respected  mem¬ 
bers  fi'om  the  organization,  developing  a  commxmications 
plan,  and  implementing  an  incentive  and  recognition  pro- 
greim  for  SPI  will  return  large  benefits. 

•  The  initial  SPI  infi*astructure  has  been  established  and 
is  reinforcing  sponsorship  and  promoting  SPI  concepts 
and  activities. 

•  Organization  has  linked  the  SPI  initiative  with  the  or¬ 
ganization’s  business  strategy. 

•  Initial  organization  communication  pian  for  the  SPI 

initiative  is  completed. 

•  Recognition  program  established  to  publicly  demon¬ 
strate  rewards  for  SPI  results. 

•  An  initial,  organization-specific  SPI  plan  has  been  cre¬ 
ated  to  guide  the  program  through  the  Initiating,  Diag¬ 
nosing  and  Establishing  phases  of  the  IDEAL  model. 
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The  Initiating  Phase 


See  Figure  1-1  on  page  17  for  a  pictorial  representation  of 
the  tasks  associated  with  the  Initiating  Phase  of  the  IDE¬ 
AL  model. 
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Figure  1-1:  Process  Flow  for  Initiating  Phase 
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Tasks 


The  tasks  for  the  Initiating  phase  are  shown  in  the  table 
below. 


Tasks 

Page 

Number 

1.1:  Getting  Started 

19 

1 .2:  Identify  Business  Needs  and  Drivers  for  Improvement 

i— - 

- - - 

21  1 

1.3:  Build  a  Software  Process  Improvement  (SPI)  Proposal 

23 

1.4:  Educate  and  Build  Support 

26  : 

1.5:  Obtain  Approval  for  SPI  Proposal  and  Initial  Resources 

28 

1 .6:  Establish  Software  Process  Improvement  Infrastructure 

30 

1 .7:  Assess  the  Climate  for  SPI 

47  1 

1 .8:  Define  General  SPI  Goals 

- j 

49  i 

1.9:  Define  the  Guiding  Principles  of  the  SPI  Program 

51  i 

1.10:  Launch  the  Program 

52 
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1-1  Getting  Started 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


The  purpose  of  this  activity  is  to  organize  a  discovery  team 

to  put  together  a  proposal  to  management  for  launching  a 

SPI  program.  This  team  will  gather  information  about 

•  current  business  needs,  organizational  policies,  and 
regulations  that  may  affect  a  SPI  program 

•  other  change  programs  or  similar  initiatives  that  exist 
in  the  organization  or  that  may  be  planned  for  the  fu- 
time 

•  ways  to  run  a  SPI  program 

The  team  will  then  select  a  specific  approach. 

•  Identify  departments  that  will  be  stakeholders  in  a  SPI 
program. 

•  Evaluate  and  select  an  approach  to  conducting  the  SPI 
program. 

•  Identify  business  needs. 

•  Identify  approaches  to  SPI. 

•  Critical  business  issues  driving  the  need  for  process  im¬ 
provement  are  identified. 

•  A  desire  to  improve  software  development  processes  is 
present. 

•  There  is  an  organization  champion(s)  for  SPI.  The 
champions  may  come  from  anywhere  in  the  organiza¬ 
tion,  including  practitioners  and  middle  or  senior  man¬ 
agement.  There  may  be  several  champions  within  the 
organization  or  only  one. 

•  The  SPI  discovery  team  exists. 

•  Existing  and  future  initiatives,  policies,  and  regulations 
that  will  affect  the  creation  of  a  SPI  program  have  been 
identified  and  analysis  of  their  effect,  either  as  barriers 
or  leverage  points  has  been  accomplished. 


CMU/SEI-96-HB-001 


19 


An  approach  to  launching  and  conducting  a  SPI  pro¬ 
gram  has  been  selected  and  support  agreements  have 
been  established.  (This  guide  is  such  an  approach,  but  it 
requires  tailoring  and  customizing  to  the  local  environ¬ 
ment.) 

Form  a  discovery  team. 

•  Select  a  SPI  champion  with  the  necessary 
leadership  skills  to  lead  the  team  and  do  early 
planning  and  sponsorship  building. 

•  Select  representatives  from  the  stakeholder 
groups  to  be  involved  in  the  development  of  the 
SPI  plans. 

Identify  the  SPI  climate  for  change. 

Identify  current  policies,  regulations,  and  initiatives 
that  will  support  or  impede  the  launching  of  a  SPI 
program.  For  example,  a  company  may  have  a  policy 
regarding  annual  management  training;  may  be  subject 
to  government  agency  regulations,  such  as  the  Food  and 
Drug  Administration;  or  may  have  an  initiative  to 
achieve  ISO  9001  certification.  These  all  may  affect  a 
SPI  program. 

Get  information  on  how  to  do  SPI. 

•  Identify  different  approaches  and  support 
groups. 

•  Select  an  approach  that  fits  the  needs  and 
environment  of  the  organization  best. 

•  Establish  consulting  and  training  support  for  the 
approach  selected. 
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1  -2  Identify  Business  Needs  and  Drivers  for 

Improvement 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


Tasks 


The  purpose  of  this  step  is  to  understand,  from  a  manage¬ 
ment  perspective,  the  key  business  needs  driving  the  re¬ 
quirement  for  a  SPI  program. 

SPI  champions  usually  have  many  good  reasons  why  an  or¬ 
ganization  should  launch  a  SPI  program,  but  their  reasons 
are  rarely  couched  in  business  terms  or  aligned  with  the  or¬ 
ganization’s  business  needs.  This  activity  will  establish  the 
need  for  a  SPI  program  in  management  business  terms, 
aligned  with  ciirrent  business  needs. 

•  Identify  key  business  needs  that  drive  a  requirement  for 
SPI. 

•  Link  SPI  program  to  business  needs. 

•  The  SPI  discovery  team  exists. 

•  Senior  management  has  articulated  the  organization’s 
business  strategy. 

•  The  key  business  needs  have  been  defined  and  links  es¬ 
tablished  as  drivers  to  a  SPI  program. 

•  High  level  description  of  the  desired  state  of  process  im¬ 
provement  for  the  organization  has  been  documented. 

•  Collect  business  needs. 

•  Review  current  vision  statements  and  SPI 
business  focus. 

•  Collect  any  current  needs  identification 
documents. 

•  Interview  key  management  stakeholders. 
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1 .0  The  Initiating  Phase 

1 .2  Identify  Business  Needs  and  Drivers  for  Improvement 


•  Review  needs  to  determine  those  that  can  be  fully  or 
partially  satisfied  through  a  SPI  program. 

•  Define  how  the  SPI  program  can  satisfy  the  business 
needs. 
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1.3 

Build  a  Software  Process  Improvement  (SPI) 

Proposal 

Purpose 

The  purpose  of  this  step  is  to  build  a  proposal  for  senior 
management  that  will  explain  what  the  SPI  program  is, 
why  it  should  be  initiated,  what  it  will  cost,  how  long  it  will 
take  to  see  results,  and  what  approach  is  selected.  The  pro¬ 
posal  should  answer  the  questions,  “What  do  we  want  to 
do?”  and  “Why  do  we  want  to  do  it?” 

This  will  lead  to  the  next  management  decision  point,  at 
which  management  decides  whether  or  not  to  go  ahead 
with  the  SPI  program  (see  Step  1.5  on  page  28). 

Objectives 

Develop  and  deliver  a  SPI  proposal. 

Entry  Criteria 

•  The  SPI  discovery  team  is  formed  and  in  place. 

•  Existing  initiatives,  policies,  and  regulations  that  will 
affect  the  creation  of  a  SPI  program  have  been  identi¬ 
fied. 

•  An  approach  to  launching  and  conducting  a  SPI  pro¬ 
gram  has  been  selected  and  SPI  consulting  support 
agreements  established. 

•  Business  needs  and  drivers  for  the  proposal  are  defined. 

Exit  Criteria 

•  The  proposal  is  completed  and  ready  to  be  delivered. 

•  Draft  of  an  organization  communication  plan  has  been 
developed. 

Tasks 

•  Identify  key  management  stakeholders  to 

•  get  inputs  for  the  proposal 

•  send  draft  proposal  to  them  for  review  and 
comment 
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The  Initiating  Phase 

Build  a  Software  Process  Improvement  (SPI)  Proposal 


•  Come  to  consensus  with  senior  management  on  the 
problem(s)  addressed  by  the  SPI  program  proposal. 

•  Establish  goals  and  objectives  for  the  improvement  pro¬ 
gram,  ensuring  consistency  with  business  objectives 
and  critical  business  needs  previously  identified.  See 
Step  1.8  on  page  49. 

•  Initiate  development  of  a  vision  of  the  desired  state  of 
the  organization’s  process  maturity. 

•  Identify  and  communicate  SPI  resource  expectations. 

•  Determine  scope. 

•  Which  departments  (R&D,  marketing, 
manufacturing,  quality,  etc.)  will  be  included 

•  What  kinds  of  software  (product,  embedded, 
mission,  support,  etc.)  will  be  included 

•  Determine  organizational  structure  for  managing  and 
coordinating  the  SPI  program,  including  roles  and  re¬ 
sponsibilities  of 

•  senior  management 

•  organization  support  groups 

•  corporate  support  groups 

•  SEPG  (determine  membership  based  on  scope  of 
improvement  program) 

•  MSG  (determine  membership  based  on  scope  of 
improvement  program,  funding  sources,  and 
management  control  requirements) 

•  other  entities 

•  Develop  high-level  plan. 

•  Develop  initial  high-level  activities  and  schedule 
through  the  Establishing  phase. 

•  Determine  basic  resom*ce  requirements  (people, 
training  needs,  travel  funds,  equipment, 
consultants),  primarily  for  the  SEPG,  key 
managers,  and  staff  in  line  organizations  and 
expected  baselining  teams. 
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1.3  Build  a  Software  Process  Improvement  (SPI)  Proposal 


•  Determine  benefits  to  the  organization,  such  as  busi¬ 
ness  value  (include  return  on  investment  if  appropri¬ 
ate),  improved  capabilities,  morale. 

•  Write  the  proposal  to  senior  management. 

•  Conduct  reviews  to  refine  draft  proposal  with  key  stake¬ 
holders. 

•  Initiate  creation  of  organization’s  SPI  communication 
plan. 
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1.0  The  Initiating  Phase 

1.4  Educate  and  Build  Support 


1.4 


Educate  and  Build  Support 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


The  purpose  of  this  activity  is  to  create  awareness,  set  ex¬ 
pectations,  and  build  support  for  the  SPI  program  across  as 
much  of  the  organization  that  will  be  affected  by  the  SPI 
program  as  possible.  This  activity  starts  early  and  contin¬ 
ues  throughout  the  entire  program,  adjusting  the  type  and 
level  of  information  presented  to  match  the  current  phase 
and  level  of  activities. 

The  intent  is  to  answer  the  question,  “What  is  going  on  and 
why  are  we  doing  this?”  Support  is  built  by  involving  the 
people  affected  by  the  program  in  the  early,  defining  parts 
of  the  program  when  they  can  more  easily  make  a  differ¬ 
ence  and  increase  their  stake  in  the  outcomes. 

•  Communicate  the  business  need  for  SPI  to  the  organiza¬ 
tion. 

•  Communicate  the  approach  that  the  organization  will 
be  taking  for  the  SPI  initiative. 

•  Introduce  and  involve  key  stakeholders  in 
communicating  and  forming  the  SPI  program. 

•  The  SPI  discovery  team  is  formed  and  in  place. 

•  Existing  initiatives,  policies,  and  regulations  that  will 
affect  the  creation  of  a  SPI  program  have  been  identi¬ 
fied. 

•  An  approach  to  launching  and  conducting  a  SPI  pro¬ 
gram  has  been  selected  and  SPI  program  support  agree¬ 
ments  established. 

•  Organization  SPI  communication  plan  is  completed. 

•  Briefing  kits  for  communications  sessions  are  complet¬ 
ed. 

•  Messages  that  must  be  communicated  at  this  point  in 
the  program  have  effectively  reached  their  audiences. 
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Tasks 


The  Initiating  Phase 
Educate  and  Build  Support 


There  is  no  real  exit  from  this  activity,  as  the  need  to  edu¬ 
cate  and  build  support  for  process  improvement  continues 
throughout  the  program. 

•  Build  (or  obtain)  a  series  of  briefings  that  can  be  tai¬ 
lored  to  various  organization  components  covering  what 
the  effort  is  all  about,  why  it  is  being  initiated,  how  it 
will  affect  the  audience,  and  what  the  desired  outcomes 
are. 

•  Develop  briefings  to  cover 

•  senior  managers  and  their  staff 

•  software  managers  and  their  staff 

•  software  practitioners 

•  other  interested  parties 

•  corporate  senior  managers  (if  applicable) 

•  Enlist  key  stakeholders  to  deliver  briefings  where  pos¬ 
sible  or  appropriate. 

•  Brief  organization  in  as  many  different  forums  as  possi¬ 
ble. 

•  Establish  dialogues  with  key  stakeholders 
during  briefings  to  help  form  the  SPI  program. 

•  Follow  up  with  key  stakeholders  to  get  feedback 
and  buy-in. 
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.0  The  Initiating  Phase 
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1.5 


Obtain  Approval  for  SPI  Proposal  and  Initial 
Resources 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


Tasks 


Present  the  SPI  proposal  to  senior  management  and  get 
their  approval  and  allocation  of  time  and  resources  neces¬ 
sary  to  launch  the  SPI  program. 

There  may  be  some  iteration  from  Step  1.1  on  page  19 
through  this  step  (1.5)  until  agreement  is  reached  on  the 
proposal  and  resources  to  continue  with  the  SPI  initiative, 
or  to  abandon  the  SPI  initiative  if  agreement  cannot  be 
reached. 

•  Obtain  approval  and  resources  from  senior  manage¬ 
ment  and  buy-in  from  other  key  stakeholders. 

•  Obtain  agreement  to  establish  MSG. 

•  Obtain  approval  for  resources  for  SEPG. 

•  Obtain  senior  management  time  participation  in  follow- 
on  activities  (MSG,  assessing  climate,  launching  SPI, 
etc.). 

•  Business  rationale  for  establishing  a  SPI  program  is 
clear. 

•  The  proposal  is  completed  and  ready  to  be  delivered. 

•  Proposal  approved. 

•  Resources  allocated. 

•  Organization  communication  updated. 

•  or 

•  Proposal  rejected  and  program  cancelled. 

•  Present  the  proposal  to  the  key  organization  stakehold¬ 
ers  and  senior  management. 

•  Obtain  approval  of  the  proposal. 
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1 .5  Obtain  Approval  for  SPI  Proposal  and  Initial  Resources 


•  Allocate  initial  resources  to  begin  work  (primarily  the 
MSG  and  SEPG). 

•  Establish  funding  strategy  (identify  who  is  responsible 
for  providing  and  managing  what  resources). 

•  Budget  for  needed  resources. 

•  Find/obtain/distribute  resources,  including  senior  man¬ 
agement  time  to  participate  in  follow-on  activities. 

•  Update  the  organization  communication  plan. 
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1.0  The  Initiating  Phase 

1 .6  Estabiish  Software  Process  Improvement  Infrastructure 


1*6  Establish  Software  Process  Improvement 

Infrastructure 


Overview  To  effectively  manage  the  SPI  program,  an  infrastructure 

must  be  in  place  or  created.  The  elements  of  the  infrastruc¬ 
ture  must  have  clearly  defined  duties  and  responsibilities 
along  with  authority  to  properly  ensure  the  success  of  the 
SPI  program.  Appendix  A.O  on  page  167  describes  the  pro¬ 
cess  improvement  infrastructure  in  more  detail. 

The  primary  purpose  for  establishing  an  infrastructure  for 
a  SPI  program  is  to  build  the  mechanisms  necessary  to  help 
the  organization  institutionalize  continuous  process  im¬ 
provement.  The  infrastructure  established  with  any  SPI 
program  is  critical  to  the  success  of  that  program.  A  solid, 
effective  infrastructure  can  sustain  a  developing  SPI  pro¬ 
gram  until  it  begins  to  produce  visible  results.  A  good  infra¬ 
structure  can  mean  the  difference  between  a  successful  SPI 
program  and  a  failure.  Unsupported  SPI  programs  can  be¬ 
come  isolated  and  die  out  during  periods  of  stress  and  ten¬ 
sion  within  their  organizations. 

Infrastructure  concepts  apply  to  both  local  (site)  SPI  pro¬ 
grams  and  to  corporate  programs  that  consist  of  many  dif¬ 
ferent  sites,  each  running  its  own  local  SPI  program.  When 
the  individual  SPI  programs  are  a  part  of  a  larger  organi¬ 
zation,  there  are  activities  that  can  be  done  and  mecha¬ 
nisms  that  can  be  established  that  will  help  ensure  that  the 
individual  programs 

•  survive  and  are  effective 

•  provide  economies  of  scale  with  reduced  site  costs 

•  enhance  sharing  of  lessons  learned  across  multiple  sites 

The  infrastructure  will  validate  the  program  and  lend  cre¬ 
dence  to  the  efforts.  The  infrastructure  will  guide  and  mon¬ 
itor  the  SPI  program  and  facilitate  allocation  of  resources. 
The  infrastructure  will  also  interact  with  external  groups 
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to  maintain  an  awareness  of  the  state  of  the  practice  relat¬ 
ing  to  process  improvement. 

When  establishing  the  SPI  infrastructure,  the  size,  struc¬ 
ture,  and  culture  of  the  organization  undertaking  the  SPI 
must  be  considered.  This  along  with  any  geographic  consid¬ 
erations  will  guide  the  creation  of  the  SPI  infrastructure  so 
that  management’s  view  of  the  SPI  program  is  absolutely 
clear. 

At  the  core  of  the  improvement  infrastructure  is  the  SEPG 
that  facilitates  the  SPI  program.  There  should  also  be  a  lo¬ 
cal  MSG  to  advise  the  SEPG  and  monitor  its  efforts.  For 
larger  organizations  that  span  multiple  sites,  or  for  efforts 
that  span  several  organizations,  a  representative  from 
each  of  the  SEPGs  or  MSGs  should  meet  to  coordinate  pro¬ 
cess  improvement  activities  across  several  SEPGs. 

In  very  large  organizations,  there  should  be  an  executive 
council  (EC)  to  deal  with  strategy  and  direction  for  the  or¬ 
ganization’s  SPI  program.  Other  components  of  the  infra¬ 
structure,  TWGs,  sometimes  known  as  process  action 
teams  (PATs),  will  come  and  go,  existing  for  finite  periods 
of  time  to  accomplish  their  specific  goals.  These  different 
entities  are  further  described  in  Appendix  A.0  on  page  167, 
which  also  includes  sample  charters  for  each  entity. 

SPI  is  a  significant  undertaking  for  any  organization,  and 
it  is  almost  impossible  to  accomplish  anything  without  a 
supporting  infrastructure.  The  management  infrastruc¬ 
ture  will  do  a  lot  of  things  for  the  SEPGs  and  TWGs  that 
are  on  the  front  lines  trying  to  accomplish  process  improve¬ 
ment. 
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The  Initiating  Phase 

Establish  Software  Process  Improvement  Infrastructure 


Purpose 


Objectives 


Entry  Criteria 
Exit  Criteria 


The  infrastructure  can 

•  provide  resources  when  they  are  needed 

•  provide  counseling  about  the  direction,  scope,  and  speed 
of  the  effort 

•  remove  roadblocks  so  the  SPI  program  proceeds 
smoothly 

•  Maintain  visibility  for  the  SPI  program. 

•  Facilitate  and  encourage  information  sharing. 

•  Capture  and  retain  lessons  learned  and  improvements 
developed. 

•  Provide  a  support  resource. 

Figure  1-2  on  page  33  shows  these  elements  as  they  sup¬ 
port  SPI. 

•  Establish  the  infrastructure. 

•  Start  ongoing  infrastructure  activities: 

•  Facilitate  the  SPI  program. 

•  Advise  and  monitor  the  efforts  of  the  SEPG. 

•  Coordinate  process  improvement  activities. 

•  Provide  visible  and  effective  sponsorship  for  the 
SPI  program 

SPI  proposal  approved  and  resovmces  allocated. 

•  Infrastructure  defined  in  terms  of  specific  people,  orga¬ 
nizational  entities,  roles  and  responsibilities,  and  inter¬ 
faces. 

•  Infrastructure  charters  created. 

•  Infrastructure  in  place  and  operating. 

Although  the  task  of  establishing  the  infrastructure  has  a 
definite  exit,  many  of  the  activities  that  are  begun  in  this 
task  start  continuous,  ongoing  activities  that  last  for  the 
life  of  the  SPI  program. 
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Subtasks 


The  subtasks  for  this  step  are  shown  in  the  table  below. 


Subtasks 

_  . 

Page 

Number 

1.6.1 :  Establish  Management  Steering  Group  (MSG) 

35  ! 

1.6.2;  Establish  Software  Engineering  Process  Group  (SEPG)  (Responsibility  of 
MSG) 

36  ! 

1.6.3;  Maintain  Visibility 

38 

1 .6.4;  Facilitate  and  Encourage  Information  Sharing 

40 

1.6.5;  Retain  Lessons  Learned  and  Improvements  Developed 

42  I 

1 .6.6;  Provide  a  Support  Network 

45  1 
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1  -6.1  Establish  Management  Steering  Group  (MSG) 


Purpose 


Objectives 


Entry  Criteria 
Tasks 


Exit  Criteria 


The  purpose  of  establishing  an  MSG  is  to  assign  project  re¬ 
sponsibility  for  the  SPI  program.  The  MSG  is  essentially 
the  project  manager  for  SPI.  It  provides  sponsorship  to  the 
effort,  arranging  for  resources  as  necessary  to  support  the 
effort.  It  also  monitors  the  progress  of  the  SPI  program  and 
provides  guidance  and  corrective  actions  as  necessary  to 
keep  the  SPI  program  linked  to  the  organization  vision 
and  business  needs. 

If  a  similar  group  already  exists,  revise/expand  their  char¬ 
ter  to  reflect  this  new  responsibility.  Membership  is  select¬ 
ed  from  the  organizations  line  management.  See  Appendix 
A.O  on  page  167  for  more  information  on  the  various  infra¬ 
structure  entities  and  their  definitions. 

Create  the  infrastructure  component  that  will  provide 
management  oversight  and  guidance  to  the  SPI  program. 

SPI  proposal  approved. 

•  Select  members,  chairperson. 

•  Define  roles  and  responsibilities. 

•  Define  relationship  with  the  SEPG,  TWGs  and  other 
parts  of  the  organization,  including  reporting  require¬ 
ments. 

•  Develop/revise  charter  for  MSG. 

•  Conduct  team  building  for  MSG  (and  between  MSG  and 
any  other  entities  defined). 

•  Develop  process  to  provide  for  succession  and  member 
replacement. 

•  MSG  members  selected. 

•  MSG  charter  developed  and  approved. 

•  MSG  leader  appointed. 
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1-6.2  Establish  Software  Engineering  Process  Group  (SEPG) 

(Responsibility  of  MSG) 


Purpose  The  purpose  of  establishing  an  SEPG  is  to  assign  responsi¬ 

bility  for  facilitation  and  coordination  of  the  SPI  program. 
The  SEPG  is  not  the  implementor  of  SPI  but  plays  the  role 
of  facilitator,  guiding  the  process  improvement  activity. 

If  a  similar  group  already  exists,  revise/expand  their  char¬ 
ter  to  reflect  this  new  responsibility.  Membership  is  select¬ 
ed  from  the  organizations  practitioners.  See  Appendix  A.0 
on  page  167,  for  more  information  on  the  various  infra¬ 
structure  entities  and  their  definitions. 

Objectives  .  Create  the  infrastructure  component  that  will  facilitate 

and  guide  the  SPI  activities. 

•  Select  qualified  personnel  for  membership. 

Entry  Criteria  SPI  proposal  approved. 

Tasks  .  Determine  SEPG  member  qualifications. 

•  Interview  and  select  SEPG  members. 

•  Define  SEPG  roles  and  responsibilities. 

•  Define  relationship  with  MSG. 

•  Define  relationships  with  TWGs  and  the  rest  of  the  or¬ 
ganization,  including  reporting,  tracking,  and  support 
requirements. 

•  Select  SEPG  leader  (if  not  already  assigned;  likely  to  be 
SPI  champion). 

•  Develop  SEPG  charter. 

•  Conduct  team  building  for  the  SEPG  (and  between 
SEPG  and  other  entities  defined). 
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1 .6.2  Establish  Software  Engineering  Process  Group  (SEPG)  (Responsibility  of  MSG) 


Exit  Criteria 


•  Develop  process  to  provide  for  succession  and  member 
replacement. 

•  Plan  for  succession  and  member  replacement. 

•  SEPG  members  selected. 

•  SEPG  charter  developed  and  approved. 

•  SEPG  leader  appointed. 
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1.6  Establish  Software  Process  Improvement  Infrastructure 

1.6.3  Maintain  Visibility 


1-6.3  Maintain  Visibility 


Purpose  The  purpose  of  maintaining  visibility  of  a  SPI  program  is  to 

•  keep  senior  management  attention  focused  on  the  long¬ 
term  program 

•  provide  information  to  the  organization  as  a  whole  to 
see  the  effort  and  progress  of  the  SPI  program 

•  provide  ongoing  recognition  of  what  is  happening  with¬ 
in  the  SPI  program  as  it  evolves 

SPI  programs  are  launched  and  sponsored  by  executive 
management,  but  they  are  often  forgotten  or  become  invis¬ 
ible  after  the  initial  fanfare  is  over.  Having  a  regular  time 
set  aside  at  all  levels  of  management  for  paying  attention 
to  the  SPI  program  keeps  the  program  in  focus  and  main¬ 
tains  its  visibility.  This  will  enable  management  to  respond 
to  situations  that  arise  at  individual  sites  before  these  sit¬ 
uations  become  crises.  Successes  can  be  shared,  and  a  com¬ 
mon  vision  and  approach  to  the  SPI  program  can  be  devel¬ 
oped  across  the  entire  organization. 

Maintaining  visibility  of  the  SPI  program  and  its  activities 
is  crucial  to  the  survival  of  the  program.  During  the  early 
part  of  the  program,  the  SPI  program  does  not  provide 
highly  visible  results.  There  is  a  tendency  to  lose  sight  of 
the  objectives  and  long-term  nature  of  the  SPI  program,  es¬ 
pecially  during  periods  of  organizational  upheaval  and  cri¬ 
sis.  Quite  often  SPI  programs  die  through  neglect  rather 
than  deliberate  termination,  as  individuals  become  more 
concerned  and  involved  with  day-to-day  crises  and  lose  fo¬ 
cus  on  the  long-term  benefits. 

The  Maintain  Visibility  activity  is  initiated  once  the  orga¬ 
nization  has  decided  to  undertake  a  SPI  program.  This  ac¬ 
tivity  will  remain  active  for  the  duration  of  the  SPI  pro¬ 
gram.  In  the  early  stages  of  the  SPI  program,  this  activity 
consists  of  building  an  awareness  and  generating  support 
for  the  undertaking.  While  the  improvement  program  is 
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1.0  The  Initiating  Phase 

1.6  Establish  Software  Process  Improvement  Infrastructure 

1 .6.3  Maintain  Visibility 


Objectives 


Entry  Criteria 
Tasks 


Exit  Criteria 


underway  this  activity  serves  to  continuously  reinforce  the 
benefits  of  the  SPI  program. 

The  organization  can  determine  the  effectiveness  of  the 
communications  activity  by  surveying  the  members  of  the 
organization  to  see  if  the  messages  are  being  heard  and  are 
understood. 

•  Keep  all  levels  of  management  informed  on  the  issues, 
progress,  and  results  of  the  SPI  program. 

•  Keep  the  entire  organization  informed  on  the  progress 
and  results  of  the  SPI  program. 

•  Publicly  recognize  efforts  of  individuals  and  teams  in 
the  SPI  program. 

SPI  program  approved  and  under  way. 

•  Conduct  management  and  practitioner  briefings  and  re¬ 
views. 

•  Establish  organization-wide  communication  vehicles 
(such  as  newsletters,  town-hall  type  meetings,  brown 
bag  seminars)  to  keep  the  entire  organization  informed 
on  the  progress  and  results  of  the  SPI  program. 

•  Establish  a  recognition  program  that  publicly  demon¬ 
strates  rewards  for  SPI  efforts  and  results. 

•  The  program  must  maintain  visibility  of  its  efforts 
throughout  its  lifetime.  There  is  no  exit  from  communi¬ 
cating  progress  and  results  unless  the  entire  program  is 
terminated. 

•  Specific  messages  must  be  effectively  communicated. 
The  members  of  the  organization  should  be  periodically 
surveyed  to  ensure  that  the  messages  are  being  re¬ 
ceived. 
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1.0  The  Initiating  Phase 

1.6  Establish  Software  Process  Improvement  Infrastructure 

1 .6.4  Facilitate  and  Encourage  Information  Sharing 


"•■6.4  Facilitate  and  Encourage  Information  Sharing 


Purpose  The  busier  SPI  programs  get,  the  less  time  there  is  to  share 

information  between  the  SEPG  and  the  rest  of  the  organi¬ 
zation,  especially  those  not  directly  involved  in  a  SPI  pro¬ 
gram,  and  also  between  other  SEPGs  in  the  organization. 
Sometimes  these  organizations  are  solving  some  of  the 
same  or  related  problems,  or  breaking  the  same  ground  on 
how  to  become  more  effective  in  their  SPI  work.  More  for¬ 
mal  and  informal  mechanisms  to  facilitate  and  encourage 
information  sharing  can  help  prevent  reinventing  the 
wheel. 

The  purpose  of  such  mechanisms  is  simply  to  cause  infor¬ 
mation  to  be  shared  in  a  regular,  structured  fashion  so  that 
such  exchanges  do  not  get  lost  in  the  day-to-day  business  of 
the  SPI  program. 

There  are  two  main  dimensions  to  information  sharing:  lo¬ 
cal  (site  information  sharing)  and  global  (information  shar¬ 
ing  between  organizations).  Local  information  is  shared 
through  a  variety  of  means  such  as  monthly  newsletters, 
brown  bag  lunches,  attendance  by  the  SEPG  at  various 
staff  meetings,  etc.  Global  information  is  shared  by  holding 
periodic  meetings  (at  least  quarterly)  where  the  SEPGs 
from  different  organizations  are  brought  together,  prefera¬ 
bly  away  from  their  work  environments,  with  a  structured 
agenda  to  share  lessons  learned,  problems  encountered, 
and  successes.  Where  several  SEPGs  are  close  to  each  oth¬ 
er  geographically,  local  software  process  improvement 
networks  (SPI  Ns)  may  be  a  vehicle  for  information  sharing. 
These  usually  meet  monthly. 
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1.0  The  Initiating  Phase 

1 .6  Establish  Software  Process  Improvement  Infrastructure 

1 .6.4  Facilitate  and  Encourage  Information  Sharing 


Objectives 


Entry  Criteria 


Tasks 


Exit  Criteria 


To  validate  the  effectiveness  of  the  information  sharing  ac¬ 
tivities,  you  can  conduct  surveys  as  to  what  information  is 

being  shared  and  the  value  of  such  sharing. 

•  Establish  periodic,  planned  SPI  program  meetings  to 
share  information  locally  about  effective  practices  and 
learn  from  others’  efforts. 

•  Establish  periodic,  planned  cross-organizational 
meetings  of  SEPGs  to  share  information  globally  about 
effective  practices  and  progress,  and  to  learn  from  other 
organizations. 

•  SPI  program  under  way. 

•  For  multi-organizational  sharing,  more  than  one 
organization  must  have  a  SPI  program  under  way. 

•  The  local  SEPG  sets  up  periodic  (perhaps  quarterly) 
meetings  that  the  key  participants  in  the  SPI  pro¬ 
gram — MSG  members,  TWG  leaders,  process  owners 
and  architects,  and  pilot  project  leaders — attend. 

•  A  corporate  SEPG  sets  up  periodic  (perhaps  annual) 
meetings  to  bring  the  various  local  SEPCJs  together. 

•  Incentives  and  recognition  are  provided  for  pairticipat- 
ing  in  local  and  global  meetings. 

•  Track  long-term  usage  of  practices  to  see  how  widely 
they  are  adopted. 

•  As  long  as  the  SPI  programs  are  running  in  organiza¬ 
tions,  information  should  be  shared  among  the  various 
participants. 

•  Meetings  should  occur  at  frequent  enough  intervals  so 
that  practices  can  be  shared  before  they  are  reinvented. 
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1.6.5  Retain  Lessons  Learned  and  Improvements  Developed 


I  -6.5  Retain  Lessons  Learned  and  Improvements  Developed 


Purpose  While  the  information-sharing  activities  described  previ¬ 

ously  facilitate  sharing  of  lessons  learned,  successes,  and 
typical  problems  and  their  resolution,  they  only  do  so  for 
the  immediate  time  frame.  As  SEPGs  evolve  and  personnel 
rotate,  these  lessons  become  lost  and  forgotten,  and  the 
SEPGs  find  themselves  “reinventing  the  wheel”  when  they 
run  into  the  same  or  similar  problem  later. 

Lessons  learned  should  be  formally  documented  and  saved 
for  future  reference.  Specific  activities  to  gather  lessons 
learned  should  be  incorporated  and  planned  into  the  SPI 
activities. 

The  SPI  program  must  establish  or  integrate  with  an  exist¬ 
ing  long-term  memory  capability  to  facilitate  the  organiza¬ 
tion’s  continued  growth  and  maturity.  To  achieve  this,  cre¬ 
ation  of  a  repository  or  process  database  is  vital.  This  is  a 
mechanism  where  lessons  learned,  successes,  and  exam¬ 
ples  of  the  artifacts  coming  out  of  SPI  programs  are  main¬ 
tained  and  distributed.  Information  should  be  regularly 
captured  on  such  things  as 

•  the  process  for  SPI 

•  processes  and  products  produced 

•  examples  of  artifacts  generated  during  a  SPI  program 
(for  example,  action  plans) 

•  solutions  developed  and  how  they  were  applied 

In  addition  to  being  used  to  collect  information,  the  sam¬ 
ples  collected  should  be  transformed  into  generic  tem¬ 
plates,  and  the  lessons  learned  folded  into  a  continuously 
updated  approach  that  is  disseminated  to  all  SPI  partici¬ 
pants.  This  kind  of  activity  can  be  done  within  the  SEPG 
and  TWGs  on  a  local  basis,  or  may  require  some  focused 
corporate  resources  to  be  effective.  For  most  effective  corpo¬ 
rate-wide  learning,  all  sites  should  contribute  to  and  draw 
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1 .6  Establish  Software  Process  Improvement  Infrastructure 

1.6.5  Retain  Lessons  Learned  and  Improvements  Developed 


from  the  collective  repository.  In  the  absence  of  a  corporate¬ 
wide  effort,  local  SEPGs  and  TWGs  could  still  perform  this 
function  for  their  organizations. 

These  lessons  learned  will  be  used  during  the  Leveraging 
phase  (page  127).  They  will  be  reviewed  and  analyzed 
when  preparing  for  the  next  cycle  through  the  IDEAL  mod¬ 
el. 


Objectives 


Entry  Criteria 


Tasks 


•  Establish  criteria  and  processes  for  information  gather¬ 
ing  and  retention. 

•  Collect  and  disseminate  lessons  learned. 

•  Develop  generic,  reusable  components  of  SPI  program. 

•  SPI  program  under  way. 

•  Local  SEPG  established. 

•  SPI  program  has  information  to  share. 

•  Establish  criteria  for  information  to  retain. 

•  Establish  processes  for  collecting,  cataloging,  and 
disseminating  information. 

•  Create  SPI  repository. 

•  Collect  and  catalog  process  information  and  lessons 
learned. 

•  Periodically  publish  index  of  materials  in  repository. 

•  Derive  generic  components  (templates,  tools,  methods, 
etc.)  for  reuse  by  other  SPI  programs. 

•  Disseminate  lessons  learned  and  generic  components  to 
all  SPI  participants. 

•  Publicize  use  of  repository  items  by  using  success  sto¬ 
ries,  recognition  programs,  etc. 

•  Track  usage  of  components,  requests  for  specific  t3q)es 
of  information,  inflow  and  outflow  of  information,  and 
other  measures  that  indicate  the  effectiveness  of  the  re¬ 
pository. 
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1.6  Establish  Software  Process  Improvement  Infrastructure 

1 .6.5  Retain  Lessons  Learned  and  Improvements  Developed 


♦  Ultimately,  assess  whether  the  repository  gets  used, 
stays  current,  and  becomes  part  of  the  standard  operat¬ 
ing  environment  of  the  organization. 

Exit  Criteria  The  collection  and  dissemination  of  information  about  SPI 

must  continue  as  long  as  the  organization  wants  to  contin¬ 
ue  to  learn  from  and  improve  on  its  past  efforts  and  not  lose 
organizational  memory. 
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1  >6.6  Provide  a  Support  Network 


Purpose  For  most  organizations,  SPI  is  a  new  activity;  thus,  new 

knowledge,  skills,  and  behaviors  must  be  learned  and  some 
old  ways  of  doing  things  stopped.  This  requires  personal  as 
well  as  organizational  change,  and  the  people  involved 
need  support  to  keep  making  progress  in  learning  new 
ways  of  doing  things. 

With  an  informal,  peer-to-peer  support  network  estab¬ 
lished,  SEPGs  and  other  SPI  participants  can  go  directly  to 
their  peers  in  other  organizations  or  at  other  sites  to  get  ad¬ 
vice  and  support.  They  can  find  qualified,  experienced  peo¬ 
ple  to  help  fill  the  gaps  where  they  might  not  have  suffi¬ 
cient  resources  to  do  something.  They  can  call  on  their 
peers  to  get  advice  and  try  out  their  ideas. 

To  make  this  effective,  they  have  to  know  their  peers  and 
trust  them.  They  may  start  to  build  a  “super”  team  consist¬ 
ing  of  SEPGs  across  all  sites,  establishing  an  informal  net¬ 
work  of  SPI  programs.  This  cannot  be  accomplished  just 
through  information-sharing  mechanisms.  Team  building 
activities  should  be  planned  and  coordinated.  Some  mech¬ 
anisms  that  have  been  used  effectively  are 

•  common  training 

•  collaboration  on  assessments 

•  joint  process  improvement  projects  across  the 
organization 

With  a  corporate  SPI  infi*astructure,  there  are  opportuni¬ 
ties  for  economies  of  scale  that  are  not  available  in  a  single¬ 
site  activity.  If  a  majority  of  the  members  of  a  single  site 
SEPG  leave  for  some  reason,  usually  the  new  group  must 
go  outside  for  new  training  and  orientation.  The  new  group 
may  even  have  to  back  up  several  steps  and  start  again 
with  all  the  facilitation  and  support  provided  at  their  start¬ 
up.  This  can  become  very  expensive  over  a  large  number  of 
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1 .0  The  Initiating  Phase 

1.6  Estabiish  Software  Process  Improvement  Infrastructure 

1 .6.6  Provide  a  Support  Network 


Objectives 


Entry  Criteria 


Tasks 


Exit  Criteria 


sites,  especially  in  an  environment  in  which  people  regular¬ 
ly  rotate  assignments,  or  in  which  staff  downsizing  is  oc¬ 
curring.  Furthermore,  SEPG  members  at  a  single  site  have 
to  translate  all  advice  from  their  facilitators  and  teachers 
to  their  context  and  have  to  keep  calling  on  that  initial 
start-up  support  organization  for  assistance  and  advice. 

•  Establish  a  broad,  informal,  company-wide  network  of 
SEPGs. 

•  Establish  programs  and  mechanisms  for  SEPGs  to  work 
together. 

•  SPI  program  underway. 

•  Local  SEPG  established. 

•  Provide  common  training  for  all  SEPGs. 

•  Plan  supporting  activities  between  SEPGs  (such  as  col¬ 
laboration  on  assessments  and  joint,  cross-organiza¬ 
tional  improvement  projects). 

•  Create  a  directory  of  SEPG  members  across  the  compa¬ 
ny  and  their  specific  areas  of  expertise. 

•  SEPG  members  spend  some  amount  of  time  outside 
their  home  organizations  helping  other  SEPGs. 

This  activity  must  continue  as  long  as  the  various  SEPG 
members  across  the  company  need  support,  which  is  likely 
to  be  as  long  as  their  own  program  is  running. 
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1.7 


Assess  the  Climate  for  SPI 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


The  purpose  of  assessing  the  climate  for  SPI  is  to  identify 
barriers  and  leverage  points  across  the  organization  that 
will  have  an  impact  on  the  SPI  program,  and  to  develop  ef¬ 
fective  plans  to  ensure  that  the  improvements  made  during 
the  SPI  program  last. 

A  substantial  portion  of  this  task  is  based  on  concepts  of 
managing  technological  change. 

•  Identify  key  organizational  barriers  to  a  SPI  program. 

•  Define  strategies  to  reduce  those  barriers. 

•  Define  strategies  to  interact  with  other  related  pro¬ 
grams  and  initiatives. 

•  Develop  a  strategy  for  enhancing  and  maintaining 
sponsorship  of  the  SPI  program. 

•  Update  the  organization’s  SPI  communications  plan. 

•  Develop  a  program  to  enhance  change  agent  abilities. 

•  MSG  and  SEPG  members  have  taken  a  course  in  man¬ 
aging  technological  change. 

•  The  infrastructure  has  been  defined  in  terms  of  specific 
people,  organizational  entities,  roles  and  responsibili¬ 
ties,  and  interfaces. 

•  The  infrastructure  is  in  place  and  operating. 

•  Organizational  diagnostics  are  complete. 

•  Sponsorship  strategies  and  organization  communica¬ 
tion  plan  have  been  completed. 

•  Interfaces  and  interactions  with  other  programs  and  in¬ 
itiatives  have  been  defined. 

•  Change  management  strategy  developed. 
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Updated  organization  SPI  communication  plan  and 
sponsorship  enhancement  and  maintenance  strategies. 

Using  organizational  diagnostics,  assess  the  history  of 
barriers  to  implementing  similar  change  programs. 

Assess  the  organization’s  culture  and  identify  related 
barriers  and  leverage  points. 

Assess  sponsorship  for  SPI  and  determine  what  is  need¬ 
ed  to  improve  it. 

Assess  current  resistance  to  a  new  SPI  program  and 
identify  related  barriers  and  leverage  points. 

Identify  what  other  improvement  activities  and  major 
developments  are  already  occurring  and  determine  how 
to  interface  and  interact  with  them. 

Develop  change  management  strategies  to  reduce  or  re¬ 
move  barriers,  capitalize  on  leverage  points,  cascade 
sponsorship  for  SPI,  manage  target  resistance  to  chang¬ 
es,  and  generally  increase  the  organization’s  capacity 
for  change. 

Update  the  organization  communication  plan  including 
messages,  audiences,  media,  sequencing,  and  monitor¬ 
ing  to  implement  the  change  management  strategies. 
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1.8 


Define  General  SPI  Goals 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


Software  process  improvement  is  a  long-term  investment. 
Clearly  defined,  measurable  goals  are  necessary  to  provide 
guidance  and  to  assist  in  developing  tactics  for  improve¬ 
ment.  They  also  allow  objective  measurement  of  the  im¬ 
provement  results. 

Good  goals  are  few  in  number,  critical  to  the  organization, 
highly  visible,  and  built  with  consensus — both  horizontally 
and  vertically.  To  build  good  goals  will  require  a  substan¬ 
tial  amount  of  bi-directional  commimication  between  dif¬ 
ferent  management  groups  and  between  management  and 
practitioners. 

Both  long-term  and  short-term  goals  are  necessary  to  focus 
the  effort.  The  goals  produced  at  this  point  tend  to  be  gen¬ 
eral  in  nature  until  sufficient  information  is  collected  to 
quantify  them.  The  quantification  step  is  described  in 
Step  3.11  on  page  88. 

•  Define  long-term  and  short-term  goals. 

•  Determine  what  measimements  are  needed  to  objective¬ 
ly  determine  goal  satisfaction. 

•  SPI  strategy  can  be  clearly  linked  to  the  vision. 

•  SPI  strategy  can  be  clearly  linked  to  the  business  plan. 

•  The  key  business  drivers  have  been  clearly  defined. 

•  Barriers  and  leverage  points  from  past  efforts  are  iden¬ 
tified  and  strategies  for  reducing  the  barriers  defined. 

•  Understanding  of  the  priorities  and  key  near-  and  long¬ 
term  business  issues. 

General  SPI  goals  defined. 
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1.8  Define  Generai  SPI  Goals 


Tasks 


♦  Gather  information  and  data  on  what  achievements 
“best  of  class”  organizations  are  accomplishing. 

•  Define  high  level  goals  from  vision,  business  plan,  key 
business  issues,  and  past  history  of  improvement  ef¬ 
forts. 
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1  -9  Define  the  Guiding  Principles  of  the  SPI  Program 


Purpose  The  SPI  program  can  be  used  as  a  model  and  a  mechanism 

for  experimenting  with  different  processes  and  behaviors 
that  are  desired.  A  typical  guiding  principle  is  to  use  the 
SPI  program  to  experiment  with  revised  management  pro¬ 
cesses,  such  as  new  forms  of  planning,  tracking,  etc.  New 
methods  can  “fail”  on  a  SPI  task  with  much  less  dramatic 
effect  on  the  organization’s  customers.  Failure  in  this  sense 
means  that  the  new  process  does  not  work  as  well  or  effi¬ 
ciently  as  initially  expected — a  common  flaw  of  first-time 
pilots  of  a  new  or  revised  process. 

Any  such  guiding  principles  should  be  docmnented  for  peo¬ 
ple  to  use  as  guidance  in  the  SPI  strategic  action  plan. 

Objectives  Define  guiding  principles  for  SPI  program. 

Entry  Criteria  Lessons  learned  from  past  efforts  are  identified. 

Exit  Criteria  Guiding  principles  defined  and  documented  in  the  “Guid¬ 

ing  Principles”  section  of  the  SPI  strategic  action  plan. 

"Tasks  .  Review  other  organizations’ guiding  principles  for  SPI. 

•  Select  and  define  guiding  principles  for  the  SPI  pro¬ 
gram. 

♦  Docxunent  guiding  principles  in  “Guiding  Principles” 
section  of  the  SPI  strategic  action  plan. 


CMU/SEI-96-HB-001 


51 


1.0  The  Initiating  Phase 

1.10  Launch  the  Program 


1-10  Launch  the  Program 


Purpose 


Objectives 
Entry  Criteria 


Exit  Criteria 


Tasks 


The  purpose  of  this  activity  is  to  move  into  the  main  part  of 
the  SPI  program  and  start  the  continuous  cycle  of  the  pro¬ 
cess  improvement  program. 

Usually  this  begins  with  an  “SEPG  kickoff’  workshop  that 
refreshes  the  memory  of  the  MSG  and  SEPG  members 
about  what  the  process  improvement  activity  is  and  what 
kinds  of  things  the  SEPG  and  MSG  will  have  to  do  in  sub¬ 
sequent  steps. 

Transition  from  initial  activities  to  ongoing  activities. 

•  SPI  proposal  approved. 

•  Sponsorship  and  organization  communication  strategy 
and  plans  completed. 

•  Interfaces  and  interactions  with  other  programs  and  in¬ 
itiatives  defined. 

•  Infrastructure  established  in  terms  of  specific  people, 
organizational  entities,  roles,  responsibilities,  and  in¬ 
terfaces. 

•  Program  and  infrastructure  in  place  and  operating. 

•  Agreement  and  approval  to  move  to  next  the  step. 

•  Learn  about  the  SPI  techniques  and  the  SPI  process  se¬ 
lected.  (Conduct  an  “SEPG  kickoff’  workshop.) 

•  Review  the  SPI  proposal. 

•  Review  organizational  assessment  results  (fi'om 
Step  1.7  on  page  47). 

•  Review  interaction  plans  for  other  programs  and  initia¬ 
tives. 

•  Obtain  senior  management  approval  to  move  to  the 
next  phase,  the  Diagnosing  phase  (page  53). 
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2.0  The  Diagnosing  Phase 


Overview  The  management  steering  group  (MSG)  must  understand 

the  organization’s  current  software  process  baseline  so  that 
it  can  develop  a  plan  that  will  achieve  the  business  changes 
specified  in  the  organization’s  software  process  improve¬ 
ment  (SPI)  goals.  The  baselining  activities  performed  in 
the  Diagnosing  phase  will  provide  this  information  into  the 
SPI  planning  and  prioritization  process. 

The  SPI  strategic  action  plan,  which  will  be  developed  after 
the  baselining  activities  are  complete,  is  critical:  it  is  need¬ 
ed  to  provide  clear  guidance  for  the  various  process  im¬ 
provement  actions  that  will  be  taken  over  the  next  few 
years.  It  should  provide  clear  business  reasons  for  conduct¬ 
ing  the  SPI  program  and  should  be  clearly  and  measurably 
linked  to  the  organization’s  business  plan  and  vision. 

The  baselines  will  provide  information  on  how  and  how 
well  the  organization  currently  performs  its  software  activ¬ 
ities.  The  knowledge  of  the  strengths  and  opportunities  for 
improvement  is  an  essential  prerequisite  for  identifying 
and  prioritizing  an  effective  and  efficient  SPI  program. 

The  primary  output  of  this  phase  is  the  Final  Findings  and 
Recommendations  Report,  which  is  produced  as  a  result  of 
the  baselining  activities.  Secondary  outputs  may  be  revi¬ 
sions  to  the  organization’s  vision  and  business  plan, 

A  recommended  minimum  set  of  baselines  includes 

•  organization  process  maturity  baseline  (See  Appendix 
C.O  on  page  203). 

•  process  description  baseline  (initial  software  process 
map) 

•  metrics  baseline  (initial  level  of  business  and  process 
metrics  to  measme  progress  against) 
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For  each  baseline,  many  effective  methods  of  gathering  in¬ 
formation  are  available.  For  the  process  maturity  baseline, 
an  authorized  lead  appraiser  can  conduct  a  Capability  Ma¬ 
turity  Model  (CMM)  -based  appraisal  for  internal  process 
improvement  (CBA IPI),  or  the  organization’s  own  person¬ 
nel  can  be  trained  to  appraise  their  process  maturity.  Ap¬ 
praisals  that  are  based  on  the  CMM  use  a  set  of  common  re¬ 
quirements  that  are  described  in  the  CMM  Appraisal 
Framework,  Version  1.0 } 

The  MSG  must  choose  the  number  and  type  of  baselines 
that  best  achieve  the  objectives  it  has  set  so  that  a  findings 
and  recommendations  report  can  be  obtained  from  each. 

Information  about  the  current  state  of  the  organization 
flows  to  the  MSG  by  means  of  the  Baseline  Findings  and 
Recommendations  Reports.  Because  the  baseline  reports 
will  not  necessarily  coincide  in  time,  information  will  flow 
irregularly.  As  information  is  available,  the  MSG  incorpo¬ 
rates  it  into  the  improvement  plans.  Baselines  do  not  deter¬ 
mine  the  strategy,  however.  The  strategy  for  improvement 
must  be  based  on  business  goals  and  needs.  The  baselines 
can  help  determine  the  current  state  of  the  organization 
with  respect  to  achieving  those  goals  or  being  capable  of 
achieving  them. 

Information  on  the  current  state  will  also  be  used  by  the 
technical  working  groups  (TWGs)  during  the  Acting  phase 
(page  93)  to  develop  process  improvement  solutions.  Keep¬ 
ing  the  momentum  of  process  improvement  between  base¬ 
lining  and  deployment  is  very  important. 

Baselines  are  intended  to  be  iterative;  the  major  baselines 
conducted  at  this  point  provide  a  snapshot  of  the  organiza¬ 
tion’s  various  capabilities,  processes,  and  measures  at  a 
certain  point  in  time.  Subsequent  cycles  through  the  IDE¬ 
AL  model  will  require  repeated  baselining  to  show  what 
progress  or  changes  have  taken  hold  in  the  organization. 
Software  maturity  baselines  should  be  repeated  every  eigh- 

1 .  Masters,  Steve;  &  Bothwell,  Carol.  CMM  Appraisal  Framework,  Version  1.0  (CMU/SEI-95-TR-001 ). 

Pittsburgh,  Pa.:  Software  Engineering  Institute,  Carnegie  Mellon  University,  1995. 
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Purpose 


Objectives 


Education/Skills 


teen  months  to  three  years.  Metrics  baselines  should  prob¬ 
ably  be  taken  more  often,  depending  on  the  business  cycle 
of  the  organization  (if  the  organization  goes  through  a  full 
cycle  only  every  two  years,  more  frequent  metrics  baselines 
would  probably  not  be  useful.  On  the  other  hand,  if  the  or¬ 
ganization  goes  through  a  product  cycle  every  three 
months,  metrics  baselines  could  be  taken  annually.) 

•  Determine  what  baselines  are  reqmred 

•  Perform  baselining  activities 

•  Produce  Findings  and  Recommendations  report 

The  purpose  of  this  phase  is  to  perform  the  baselining  ac¬ 
tivity  to  get  a  picture  of  the  organizations  current  strengths 
and  weaknesses.  This  information  gathered  from  the  base¬ 
lines  will  then  be  used  to  initiate  development  of  the  SPI 
strategic  action  plan  that  will  provide  guidance  and  direc¬ 
tion  to  the  SPI  program  in  the  years  to  come. 

The  baselining  activities  must  be  self-verifying.  The  credi¬ 
bility  of  the  baselines  depends  on  their  perceived  ability  to 
extract  real,  meaningful  information  from  the  organization 
and  present  it  back  to  the  organization  in  a  coherent,  ac¬ 
tionable  form. 

•  Understand  the  working  of  the  current  processes  and 
the  organizational  interactions  and  how  they  contribute 
to  the  organization’s  business. 

•  Gather  information  on  the  current  strengths  and  oppor¬ 
tunities  for  improvement  in  the  organization  for  input 
to  the  SPI  strategic  action  planning  process. 

•  Build  involvement,  fi'om  the  senior  management  team 
down  to  the  practitioners,  for  process  improvement 
tasks  that  will  make  the  work  of  the  organization  more 
effective. 

•  Detail  the  starting  point  for  measuring  improvement 

Training  and  skill  development  for  the  Diagnosing  phase  is 
shown  in  the  following  table. 
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Education/Skills 

MSG 

SEPG 

TWG 

Appraisal 

Team 

Practitioners 

Interviewing  skills 

X 

X 

X 

;  Data  reduction  skills 

X 

X 

Business  knowledge 

X 

X 

X 

:  Baselining  method 

X 

X 

1  Team  skills 

X 

X 

X 

i  Change  management 

X 

X 

X 

1 

Commitment 


Communication 


Entry  Criteria 


The  commitment  that  senior  management  makes  for  the 
Diagnosing  phase  is  the  time,  resources  and  training  re¬ 
quired  to  complete  the  phase. 

All  members  of  the  organization  are  also  making  a  commit¬ 
ment  that  the  baselines  will  be  conducted  under  an  agree¬ 
ment  of  confidentiality  and  that  no  attempt  to  find  out  the 
source  of  any  piece  of  information  will  be  tolerated. 

Each  of  the  baselining  activities  will  have  specific  commu¬ 
nication  needs.  In  addition,  getting  the  organization  ready 
for  baselining  will  require  considerable  communication,  es¬ 
tablishing  dialogue  between  various  levels  and  areas  in  the 
organization  to  maximize  the  effectiveness  of  the  baselin¬ 
ing  teams. 

Communicating  the  results  of  the  baselining  activities  will 
have  several  positive  effects  on  the  SPI  program.  It  will 
demonstrate  that  there  are  no  secrets  regarding  the  SPI 
program;  and  it  will  give  everybody  a  clear  understanding 
of  the  strengths  and  opportunities  for  improvement  that 
the  organization  faces. 

•  SPI  infrastructure,  particularly  MSG  and  software  en¬ 
gineering  process  group  (SEPG),  is  in  place  and  operat¬ 
ing. 

•  Resources  are  available  to  perform  the  baselines 

•  The  MSG  has  decided  that  the  SPI  strategic  action  plan 
needs  to  be  updated. 
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Exit  Criteria 


•  The  organization’s  vision,  business  plan,  and  SPI  goals 
are  S3niergistic. 

•  Baseline  Findings  and  Recommendation  Report  deliv¬ 
ered  to  the  MSG  and  accepted. 

•  The  draft  of  the  SPI  strategic  action  plan  is  initiated. 


See  Figure  2-1  on  page  58  for  a  pictorial  representation  of 
the  tasks  associated  with  the  Diagnosing  phase  of  the  IDE¬ 
AL  model. 
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Figure  2-1 :  Process  Flow  for  Diagnosing  Phase 
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Tasks  The  tasks  for  the  Diagnosing  phase  are  shown  in  the  table 

below. 


Tasks  Page 


2.1:  Determine  What  Baseline(s)  Are  Needed 

60 

2.2:  Plan  for  the  Baseline(s) 

62 

2.3:  Conduct  Baseline(s) 

63 

i 

2.4:  Present  Findings 

64 

‘  2.5:  Develop  Final  Findings  and  Recommendations  Report 

i - - - - - 

65 

I 

I  2.6:  Communicate  Findings  and  Recommendations  to  Organization  66 
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2.1 


Determine  What  Baseline(s)  Are  Needed 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


The  organization  has  compelling  reasons  for  undertaking  a 
SPI  program.  The  purpose  of  deciding  how  many  and  what 
type  of  baselines  are  to  insure  that  the  focus  of  the  SPI  pro¬ 
gram  is  linked  to  the  business  needs  of  the  organization. 

Determining  what  to  baseline  and  how  to  baseline  is  a  de¬ 
cision  that  very  much  depends  on  the  organization.  Many 
software  organizations  will  have  certain  t3^es  of  baselines 
determined  for  them,  such  as  Software  Engineering  Insti¬ 
tute  (SEI)  software  capability  evaluations  (SCEs)  for  gov¬ 
ernment  contracts,  ISO  9000  certifications,  Malcolm  Bald¬ 
ridge  evaluations,  or  internal  company  audits.  Even  in  the 
face  of  “external”  baselines,  an  organization  should  create 
its  own  baseline  activities  that  can  be  properly  tuned  to 
meet  the  business  and  information  goals  of  the  organiza¬ 
tion. 

•  Determine  how  many  baselines  to  perform. 

•  Determine  what  type  of  baselines  to  perform. 

•  Understanding  of  the  impetus  for  SPI. 

•  Understanding  of  the  purpose  of  the  different  baseline 
types. 

•  Infrastructure  established  and  operating  (MSG  and 
SEPG). 

•  Understanding  of  the  structure  and  function  of  the  or¬ 
ganizational  components. 

•  Agreement  on  types  of  baselines  to  perform. 

•  Agreement  on  number  of  baselines  to  perform. 
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Tasks 


The  Diagnosing  Phase 

Determine  What  Baseline(s)  Are  Needed 


•  Review  organization  structure  and  responsibilities  of 
organization  components. 

•  Evaluate  baseline  information  needed  against  organi¬ 
zation  structure  and  business  drivers  for  SPI. 
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2.2  Plan  for  the  Baseline(s) 


2.2 


Plan  for  the  Baseiine(s) 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


Tasks 


To  accomplish  the  baselining  activities  requires  a  signifi¬ 
cant  amount  of  coordination  of  people,  data,  facilities, 
training  activities  and  support  services. 

This  activity  may  repeat  some  of  the  work  done  in  the  Ini¬ 
tiating  phase  (page  11).  Sometimes  this  repetition  is  not 
needed,  but  often,  the  MSG  has  different  members  than 
those  who  set  up  the  SPI  program,  and  they  will  need  to 
cover  some  of  the  same  topics  to  develop  their  own  under¬ 
standing  and  strategy.  When  this  step  is  entered  as  a  result 
of  a  subsequent  cycle  through  the  IDEAL  model,  these  top¬ 
ics  should  be  reviewed  at  a  minimum. 

•  Insure  that  all  aspects  of  the  baselining  activities  are 
taken  into  account  and  have  been  planned  for. 

•  Document  the  activities  needed  to  accomplish  the  base¬ 
lines. 

•  Infrastructure  is  in  place  and  operating  (MSG  and 
SEPG). 

•  Baselining  team  selected. 

•  Types  of  baselines  to  perform  are  identified. 

Plan  for  conducting  the  baselines  has  been  created  and  ap¬ 
proved.  Roles  and  responsibilities  defined  and  docxunented 
in  the  “Organization”  section  of  the  SPI  strategic  action 
plan. 

•  Review  activities  for  baselining  efforts. 

•  Review  resources  required  for  baselining  efforts. 

•  Recruit  baselining  team. 

•  Train  baselining  team  in  appraisal  method(s). 
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2.3  Conduct  Baseline(s) 


2.3 


Conduct  Baseline(s) 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


Tasks 


The  purpose  of  conducting  the  baselines  is  to  gather  the 
factual  information  required  to  support  the  SPI  effort.  The 
information  gathered  will  present  a  snapshot  of  the  organi¬ 
zations  strengths  and  weaknesses  relative  to  its  software 
development  and  software  development  management  prac¬ 
tices. 

Gather  actual  information  regarding  the  strengths  and 
weaknesses  of  the  organization  processes  used  in  software 
development  activities. 

•  Consensus  and  agreement  on  the  baseline  activities 
schedule. 

•  Baselining  team  selected  and  trained. 

•  Agreement/understanding  regarding  confidentiality  of 
the  findings  data. 

•  Policies,  procedures  and  guidelines  that  the  organiza¬ 
tion  has  established  for  use  in  its  software  development 
activities  are  readily  available. 

•  Baselining  team  has  information  to  create  a  findings 
and  recommendations  report. 

•  Outbriefing  for  the  baseline  participants  has  been  pre¬ 
pared. 

•  Interview  members  of  the  software  development  staff. 

•  Interview  members  of  the  software  development  man¬ 
agement  staff. 

•  Review  and  analyze  policy,  procedures,  and  guidelines 
for  software  development  activities. 

•  Validation  of  findings  by  review  with  participants. 
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2.4  Present  Findings 


2.4 


Present  Findings 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


The  baselining  team,  at  the  end  of  its  baselining  data  col¬ 
lection  activities,  presents  to  the  participants  what  it  has 
found.  This  is  in  the  form  of  a  briefing  that  describes  the 
method  used,  the  participants,  areas  of  investigation,  and 
strengths  and  weaknesses  that  have  been  found. 

•  Provide  initial  feedback  to  the  participants  on  the  re¬ 
sults  of  the  baselining  activities. 

•  Build  support  and  consensus  regarding  the  validity  of 
the  findings. 

•  Baselining  data  collection  activities  completed. 

•  Baselining  team  has  reached  consensus  on  the 
strengths  and  weaknesses  discovered. 

Briefing  of  the  findings  to  all  participants  has  been  con¬ 
ducted. 


Tasks  Prepare  briefing  for  participants  that  includes 

•  method  used 

•  data  soiirces 

•  strengths 

•  weaknesses 

•  next  steps 
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2.5  Develop  Final  Findings  and  Recommendations  Report 


2.5 


Develop  Final  Findings  and  Recommendations 
Report 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


Tasks 


The  Final  Findings  and  Recommendations  Report  docu¬ 
ments  the  baselining  effort  and  provides  a  lasting  repre¬ 
sentation  of  the  organizations  current  state.  The  baselining 
team  will  develop  a  set  of  recommendations  to  go  along 
with  the  findings  that  were  discovered  during  the  baselin¬ 
ing  activity. 

The  baselines,  particularly  the  process  maturity  baseline, 
t5rpically  identify  issues  and  provide  recommendations 
based  on  a  much  broader  consensus  than  may  have  been 
available  before.  These  issues  and  recommendations  serve 
to  provide  some  guidance  and  often,  a  prioritization  of  ac¬ 
tions. 

The  results  of  the  baselines  will  be  incorporated  into  the 
SPI  strategic  action  plan  and  reconciled  with  other  existing 
and/or  planned  improvement  efforts.  This  will  result  in  a 
single  strategy  dealing  with  all  software  process  improve¬ 
ment  actions  and  all  related  improvement  efforts  affecting 
the  same  groups  of  people. 

Create  a  set  of  recommendations  that  address  each  of  the 
findings  fi*om  the  baselining  effort. 

•  Findings  briefing  from  end  of  baselining  activity  avail¬ 
able. 

•  Artifacts  that  were  produced  or  reviewed  during  the 
basehning  activity  are  available. 

A  Final  Findings  and  Recommendations  Report  has  been 
agreed  upon  and  created. 

•  Review  data  collected  during  baselining  activities  to  de¬ 
velop  recommendations  regarding  potential  solutions. 

•  Write  Final  Findings  and  Recommendations  Report. 
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2.6  Communicate  Findings  and  Recommendations  to  Organization 


2.6 

Communicate  Findings  and  Recommendations 
to  Organization 

Purpose 

People  will  be  wondering  about  all  the  activity  that  was  oc¬ 
curring  during  the  baselining.  To  alleviate  any  fears  that 
may  have  developed,  or  that  could  develop,  it  is  recom¬ 
mended  that  the  results  of  the  baselining  activities  be  com¬ 
municated  to  the  entire  organization. 

The  organization  can  accomplish  this  by  holding  a  series  of 
briefings  such  that  all  members  of  the  organization  hear 
the  same  message.  This  will  contribute  to  building  sponsor¬ 
ship  and  support  for  the  SPI  program. 

Objectives 

•  Gain  support  and  sponsorship  for  SPI. 

•  Gain  consensus  on  areas  that  SPI  will  be  addressing. 

•  Gain  additional  input  regarding  potential  solutions. 

•  Tell  organization  what  the  next  steps  are. 

Entry  Criteria 

•  Final  Findings  and  Recommendations  completed. 

•  Outbriefing  from  baselining  activities  is  available. 

Exit  Criteria 

•  All  members  of  the  organization  have  heard  the  same 
message  and  understand  what  the  next  steps  are. 

♦  Documented  findings  and  recommendations  distributed 
to  employees. 

Tasks 

Prepare  a  briefing  for  all  employees  of  the  organization  on 
results  of  baselining  activities  and  next  steps. 
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3.0  The  Establishing  Phase 


Overview  Creating  the  strategic  action  plan  for  software  process  im¬ 

provement  (SPI)  is  one  of  the  most  critical  in  the  SPI  initia¬ 
tive — and  most  often  neglected.  This  is  where  the  manage¬ 
ment  team  develops  or  updates  a  SPI  strategic  action  plan, 
based  on  the  organization’s  vision,  business  plan,  and  past 
improvement  efforts,  along  with  the  findings  from  the  base¬ 
lining  efforts. 

This  is  a  step  that  is  repeated  as  needed.  Usually  it  is  trig¬ 
gered  by  a  lack  of  an  action  plan  for  an  organization  on  its 
first  cycle  through  the  IDEAL  model.  For  those  organiza¬ 
tions  on  a  subsequent  cycle,  this  step  can  be  triggered  by  a 
need  to  update  the  previous  plan,  goals,  or  directions. 

The  management  steering  group  (MSG)  has  the  responsi- 
bihty  for  creation  of  the  SPI  strategic  action  plan.  In  a 
sense,  this  is  the  creation  of  a  “management”  baseline,  sim¬ 
ilar  to  the  more  process-oriented  or  technical  baselines  de¬ 
veloped  in  the  Diagnosing  phase  (page  53). 

There  is  a  strong  tendency  to  delegate  this  step  to  the  soft¬ 
ware  engineering  process  group  (SEPG).  Experience  has 
shown,  however,  that  this  usually  is  not  the  best  approach. 
Line  managers  must  demonstrate  their  active  sponsorship 
by  taking  the  time  to  be  actively  involved  in  developing  this 
plan,  owning  it,  and  committing  to  it.  Just  as  the  practitio¬ 
ners  and  middle  management  develop  ownership  of  the 
technical  baselines  and  issues  identified  through  their  in¬ 
volvement,  so  must  the  senior  management  develop  owner¬ 
ship  and  consensus  on  the  directions  to  be  taken  and  how 
to  get  there. 

Without  a  solid  strategy  to  guide  the  SPI  program,  it  will 
have  a  tendency  to  “drift”  with  the  problems  and  priorities 
of  the  month  (or  day  in  some  cases),  causing  the  initiative 
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to  degenerate  into  not  much  more  than  another  fire-fight¬ 
ing  activity. 

The  MSG  begins  by  determining  what  kind  of  strategic 
planning  process  it  will  follow.  Most  organizations  have 
their  favorite  approach  to  strategic  planning.  Regardless  of 
the  specific  method  used,  the  important  thing  is  to  develop 
a  solid  plan. 

The  MSG  then  reviews  the  organization’s  vision,  business 
plan,  past  improvement  performance,  and  current  key 
business  issues  in  order  to  determine  how  the  SPI  program 
fits.  It  then  considers  the  results  of  baselining  activities 
and  incorporates  these  results  into  the  SPI  strategic  action 
plan.  The  MSG  also  integrates  the  SPI  strategic  action  plan 
with  the  organization’s  vision  and  business  plan,  making 
modifications  and  revisions  as  necessary. 

The  SPI  strategic  action  plan  will  be  based  on  the  results  of 
the  baselining  efforts  performed  in  the  Diagnosing  phase  of 
IDEAL,  the  organization  improvement  goals,  and  the  re¬ 
sources  available.  It  should  provide  guidance  for  the  overall 
SPI  program,  define  the  long  range  goals  and  address  how 
those  goals  will  be  reached.  It  is  important  that  the  process 
improvements  are  driven  by  business  needs,  as  opposed  to 
process  improvement  for  its  own  sake. 

There  is  a  strong  temptation  at  this  point  to  immediately 
begin  making  changes.  Experience  shows  that  without 
careful  planning,  the  efforts  will  eventually  falter,  get  side¬ 
tracked,  or  will  not  meet  the  unwritten  expectations  of  se¬ 
nior  management.  The  reason  for  the  plans  is  not  just  to 
identify  the  improvement,  but  to  meet  the  organization’s 
critical  business  needs  by  installing  those  improvements 
across  the  organization.  Identification  of  the  improvements 
is  often  the  easiest  part.  Getting  everyone  throughout  the 
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organization  to  change  the  way  they  do  things  is  always  the 
most  difficult  part  of  any  improvement  effort. 

Purpose  The  purpose  of  this  step  is  to  develop  or  refine  a  SPI  stra¬ 

tegic  action  plan  that  will  provide  gmdance  and  direction  to 
the  SPI  program  in  the  years  to  come.  The  SPI  strategic  ac¬ 
tion  plan  is  critical  in  that  it  is  needed  to  provide  clear  guid¬ 
ance  to  the  various  process  improvement  actions  that  will 
be  taken  over  the  next  few  years.  It  should  provide  clear 
business  reasons  for  conducting  the  SPI  program  and 
should  be  clearly  and  measurably  linked  to  the  organiza¬ 
tion’s  vision  and  business  plan. 

The  primary  output  of  this  step  is  the  SPI  strategic  action 
plan.  Secondary  outputs  may  be  revisions  to  the  organiza¬ 
tion’s  vision  and  business  plan. 

Objectives  •  Develop/update  a  long-term  (three-  to  five-year)  SPI 

strategic  action  plan  that  encompasses  the  entire  orga¬ 
nization’s  software  process  improvement  activities  and 
integrates  them  with  any  other  total  quality  manage¬ 
ment  (TQM)  initiatives  already  planned  or  in  process. 

•  Develop/update  long  range  (three-  to  five-year)  and 
short  term  (one-year)  measurable  goals  for  the  organi¬ 
zations  SPI  program. 

•  Integrate  the  baseline  findings  and  recommendations 
into  the  SPI  strategic  action  plan. 

•  Integrate  the  SPI  strategic  action  plan  with  the  organi¬ 
zation’s  business  plan,  mission,  and  vision. 

Education/Skills  Training  and  skill  development  for  the  Establishing  phase 

is  shown  in  the  following  table 


Training 

MSG 

SEPG 

TWG 

Line 

Managers 

Practitioners 

Strategic  planning 

X 

X 

Team  skills 

X 

X 

X 

Vision  development 

X 

X 

Sponsorship 

X 

X 

X 
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Training 

MSG 

SEPG 

TWG 

Line 

Managers 

Practitioners 

Facilitation 

X 

X 

X 

Business  planning 

X 

X 

X 

Commitment 


Communication 


Entry  Criteria 


Exit  Criteria 


This  step  requires  a  substantial  commitment  from  senior 
management,  primarily  of  their  own  time,  to  work  on  de¬ 
veloping  the  SPI  strategic  action  plan.  Senior  managers 
must  commit  to  leading  the  SPI  program  by  demonstrating 
to  everyone  that  even  they  are  willing  to  take  the  time  to 
develop  a  good  plan  for  their  team’s  activities  and  then  to 
follow  it.  In  the  process,  senior  management  should  learn 
and  use  the  same  methods  and  techniques  that  the  techni¬ 
cal  working  groups  (TWGs)  will  have  to  learn.  Demonstrat¬ 
ing  visible  sponsorship  in  this  way  can  go  a  long  way  to¬ 
ward  convincing  people  that  management  is  serious  about 
software  process  improvement. 

The  MSG  will  be  communicating  with  other  (non-software) 
senior  management  in  developing  objectives  and  goals.  The 
baseline  teams  have  reported  issues,  results,  and  recom¬ 
mendations,  which  will  support  and  be  incorporated  into 
the  SPI  strategic  action  plan. 

•  The  SPI  infrastructure  is  in  place  and  operating. 

•  The  MSG  has  decided  that  the  SPI  strategic  action  plan 
needs  to  be  updated. 

•  Baselining  activities  have  been  completed. 

•  The  SPI  strategic  action  plan  is  complete  and  approved. 

•  T^e  organizations  vision,  business  plan,  and  SPI  strate¬ 
gic  action  plan  are  synergistic. 


See  Figure  3-1  on  page  71  for  a  pictorial  representation  of 
the  tasks  for  the  Establishing  phase. 
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Figure  3-1 :  Process  Flow  for  Establishing  Phase 
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Tasks 


The  tasks  for  the  Establishing  phase  are  shown  in  the  table 
below. 


Tasks 

Page 

Number 

3.1:  Select  and  Get  Training  in  a  Strategic  Planning  Process 

73  1 

3.2:  Review  Organization’s  Vision 

74 

3.3:  Review  Organization’s  Business  Plan 

76 

3.4:  Determine  Key  Business  Issues 

78 

3.5:  Review  Past  Improvement  Efforts 

80 

3.6:  Describe  the  Motivations  to  Improve 

81 

3.7:  Identify  Current  and  Future  (Planned)  Improvement  Efforts 

82 

3.8:  Finalize  Roles  and  Responsibilities  of  the  Various  Infrastructure  Entities 

84  I 

3.9:  Prioritize  Activities  and  Develop  Improvement  Agenda 

86 

3.10:  Reconcile  the  Existing/Planned  Improvement  Efforts  with  the  Baseline 

Findings  and  Recommendations 

i . . 

87 

3.1 1 :  Transform  the  General  Software  Process  Improvement  (SPI)  Goals  to  Specific 
Measurable  Goals 

! - - - - 

88  i 

1 

3.12:  Create/Update  the  SPI  Strategic  Plan 

89 

3.13:  Build  Consensus,  Review,  and  Approve  the  SPI  Strategic  Plan  and  Commit 
Resources  to  Action 

90 

I  3.14:  Form  the  Technical  Working  Group  (TWG) 

91 
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3.1  Select  and  Get  Training  in  a  Strategic  Planning  Process 


3.1 


Select  and  Get  Training  in  a  Strategic  Planning 
Process 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


Tasks 


The  purpose  of  this  activity  is  to  choose  a  consistent  ap¬ 
proach  to  planning  for  the  SPI  program  and  to  develop 
skills  in  building  a  solid  planning  foundation  upon  which  to 
sustain  the  SPI  program. 

•  Select  a  planning  process. 

•  Train  the  MSG  and  SEPG  in  the  process  and  methods. 

The  SPI  infrastructure,  particularly  the  MSG  and  SEPG,  is 
in  place  and  operating  and  has  started  a  strategic  planning 
effort. 

The  MSG  and  SEPG  have  completed  training  in  the  pro¬ 
cess. 

•  Review  strategic  planrung  methods  already  in  use. 

•  Review  planning  needs  for  the  SPI  program. 

•  Select  a  planning  process  and  approach. 

•  Contract  for,  schedule,  and  hold  planning  training. 
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3.2  Review  Organization’s  Vision 


3.2 


Review  Organization’s  Vision 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


The  purpose  of  this  activity  is  to  clearly  link  the  SPI  strat¬ 
egy  to  the  organization’s  vision  and  direction  so  that  guid¬ 
ance  to  the  SPI  program  can  be  consistent  with  guidance  to 
other  activities  within  the  organization. 

This  activity  may  repeat  some  of  the  work  done  in  the  Ini¬ 
tiating  phase  (page  11).  Sometimes  this  repetition  is  not 
needed,  but  often,  the  MSG  has  different  members  than 
those  who  initiated  the  SPI  program,  and  they  will  need  to 
cover  some  of  the  same  topics  to  develop  their  own  under¬ 
standing  and  strategy.  When  this  step  is  entered  as  a  result 
of  a  subsequent  cycle  through  the  IDEAL  model,  these  top¬ 
ics  should  be  reviewed  at  a  minimum. 

•  Review  and  possibly  modify  current  vision. 

•  Generate  new  vision  if  one  does  not  exist  or  if  the  exist¬ 
ing  one  is  not  adequate. 

•  Identify  goals  and  motivations  for  the  SPI  program. 

The  MSG  and  the  SEPG  have  completed  training  in  the 
strategic  planning  process. 

•  The  SPI  goals  that  are  driven  by  the  vision  are  identi¬ 
fied. 

•  The  motivations  for  the  SPI  program  that  derive  from 
the  vision  are  identified. 

•  The  vision  and  SPI  strategy  are  synergistic. 


74 


CMU/SEI-96-HB-001 


3.0 

3.2 


Tasks 


The  Establishing  Phase 
Review  Organization’s  Vision 


•  Review  existing  vision  for  adequate  linkage  to  SPI  pro¬ 
gram. 

•  Modify  or  generate  new  vision  if  current  one  is  inade¬ 
quate. 

•  Identify  goals  for  the  SPI  program,  based  on  the  vision. 

•  Identify  motivations  for  the  SPI  program  based  on  the 
vision. 


CMU/SEI-96-HB-001 


75 


3.0  The  Establishing  Phase 

3.3  Review  Organization’s  Business  Plan 


3.3 


Review  Organization’s  Business  Plan 


Purpose 


Objectives 


Entry  Criteria 


The  purpose  of  this  activity  is  to  clearly  link  the  SPI  strat¬ 
egy  to  the  organization’s  business  plan  so  that  guidance  to 
the  SPI  program  can  be  consistent  with  guidance  to  other 
activities  within  the  organization.  While  not  all  process  im¬ 
provement  activities  can  easily  be  linked  to  a  business  plan 
or  goals,  that  does  not  mean  that  they  are  not  needed.  Some 
things  must  be  done  because  they  make  the  business  run 
better,  but  they  do  not  directly  contribute  to  the  bottom 
line. 

This  activity  may  repeat  some  of  the  work  done  in  the  Ini¬ 
tiating  phase  (page  11).  Sometimes  this  repetition  is  not 
needed,  but  often,  the  MSG  has  different  members  than 
those  who  set  up  the  SPI  program,  and  they  will  need  to 
cover  some  of  the  same  topics  to  develop  their  own  under¬ 
standing  and  strategy.  When  this  step  is  entered  as  a  result 
of  a  subsequent  cycle  through  the  IDEAL  model,  these  top¬ 
ics  should  be  reviewed  at  a  minim\im. 

•  Review  and  possibly  modify  ciirrent  business  plan. 

•  Generate  new  business  plan  if  one  does  not  exist  or  if 
the  existing  plan  is  not  adequate. 

•  Identify  goals  and  other  (possibly  competing)  initia¬ 
tives. 

•  The  MSG  and  SEPG  have  completed  training  in  the 
strategic  planning  process. 

•  Organizations  vision  is  defined  and  communicated. 
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Review  Organization’s  Business  Plan 


Exit  Criteria 


Tasks 


The  SPI  goals  that  are  driven  by  the  business  plan  are 
identified. 

Other  improvement  efforts  that  complement  or  compete 
with  the  SPI  program  are  identified. 

The  business  plan  and  SPI  strategic  plan  are  synergis¬ 
tic. 

Review  existing  business  plan  for  adequate  linkage  to 
SPI  program. 

Modify  or  generate  new  business  plan  if  current  one  is 
inadequate. 

Identify  goals  for  the  SPI  program  driven  by  the  busi¬ 
ness  plan. 

Identify  other  initiatives  that  may  support  or  compete 
with  the  SPI  progreun  and  the  degree  of  impact. 
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3.4  Determine  Key  Business  Issues 


3.4  Determine  Key  Business  Issues 


Purpose  Unless  the  SPI  program  is  driven  by  the  current  business 

needs  and  understood  and  agreed  to  by  management,  it 
will  likely  be  difficult  to  sustain  the  program  over  the  long 
haul.  This  is  because  it  will  be  difficult  to  clearly  demon¬ 
strate  to  senior  management  that  the  initiative  is  achiev¬ 
ing  real  value  for  the  organization  in  business  terms. 

The  key  business  needs  have  to  be  clearly  defined,  measur¬ 
able,  and  understood  to  provide  a  common  view  to  the  SPI 
teams.  Improvements  should  be  selected  based  in  part  on 
their  ability  to  satisfy  these  business  needs.  As  described 
previously,  not  all  process  improvement  activities  can  eas¬ 
ily  be  linked  to  current  business  issues;  however,  the  busi¬ 
ness  issues  identified  should  be  used  to  prioritize  SPI 
projects. 

This  activity  may  repeat  some  of  the  work  done  in  the  Ini¬ 
tiating  phase  (page  11).  Sometimes  this  repetition  is  not 
needed,  but  often,  the  MSG  has  different  members  than 
those  who  set  up  the  SPI  program,  and  they  will  need  to 
cover  some  of  the  same  topics  to  develop  their  own  under¬ 
standing  and  strategy.  When  this  step  is  entered  as  a  result 
of  a  subsequent  cycle  through  the  IDEAL  model,  these  top¬ 
ics  should  be  reviewed  at  a  minimum. 

Objectives  Determine  the  key  business  issues  driving  the  need  for 

software  process  improvement. 

Entry  Criteria  .  The  MSG  and  SEPG  have  completed  training  in  a  plan¬ 

ning  process. 

•  Organizations  vision  is  documented. 

•  Organization’s  business  plan  is  up  to  date. 
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3.4  Determine  Key  Business  Issues 


Exit  Criteria 


Tasks 


The  key  business  drivers  have  been  clearly  defined. 

Criteria  for  prioritizing  SPI  projects  have  been  devel¬ 
oped. 

Review  the  current  short-term  and  long-term  business 
issues  as  they  affect  SPI. 

Develop  prioritization  criteria  for  selecting  and  launch¬ 
ing  SPI  projects,  based  in  part  on  the  identified  business 
issues. 
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3.5 


Review  Past  Improvement  Efforts 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


Tasks 


People  typically  repeat  past  behaviors,  including  those  that 
lead  to  success  and  those  that  do  not.  The  organization 
must  ensure  that  mistakes  are  not  repeated  that  may  have 
caused  similar  initiatives  to  fail  in  the  past. 

The  information  collected  in  Step  1.7  on  page  47  is  re¬ 
viewed  and  analyzed,  identifying  past  change  or  improve¬ 
ment  projects  and  assessing  how  successful  or  unsuccessful 
they  were  and  why. 

Review  past  change  and/or  improvement  efforts  and  iden¬ 
tify  successful  practices  to  leverage  and  unsuccessful  prac¬ 
tices  to  avoid. 

•  The  MSG  and  SEPG  have  completed  training  in  a  plan¬ 
ning  process. 

•  Assessment  data  from  Step  1.7  is  available. 

Barriers  and  leverage  points  from  past  efforts  are  identi¬ 
fied  and  strategies  for  reducing  the  barriers  defined  for  this 
initiative. 

•  Identify  successful  and  unsuccessful  change  or  improve¬ 
ment  projects  and  determine  what  made  them  so. 

•  Complete  necessary  assessments  from  the  Managing 
Technological  Change  course  (if  not  already  done  in 
Step  1.7). 

•  Define  strategies  to  deal  with  trends  and  barriers  iden¬ 
tified  by  organizational  diagnostics. 
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3.6 


Describe  the  Motivations  to  Improve 


Purpose  People  must  imderstand  why  the  organization  is  spending 

so  much  time  and  effort  on  a  SPI  program.  As  their  under¬ 
standing  grows  so  will  their  support.  They  must  be  moti¬ 
vated  to  join  in  the  effort  and  assist  it. 

The  motivation  should  address  the  following  points; 

•  Why  change? 

•  What’s  wrong  with  the  status  quo? 

•  Why  should  I  care? 

•  When  will  I  be  affected  (immediately  or  sometime  in  the 
future)? 

T5rpically,  successful  motivations  sell  the  pain  of  the  status 
quo,  as  opposed  to  selling  the  promise  of  the  desired  state. 
These  motivations  should  be  documented  in  the  SPI  strate¬ 
gic  action  plan.  Also,  the  communication  plan  should  be  up¬ 
dated  to  insure  that  communications  of  the  motivations  to 
improve  is  given  to  the  entire  organization. 

Objectives  Define  motivations  for  SPI  program. 

Entry  Criteria  Motivations  identified  from  the  vision  or  similar  sources. 


Exit  Criteria  Defined  motivations  are  documented  in  SPI  strategic  ac¬ 

tion  plan  (“Motivations”  section). 

Tasks  .  Build  list  of  motivations  fi-om  the  goals  and  problems 

identified  in  previous  steps. 

•  Frame  motivations  in  terms  of  the  difference  between 
the  current  state  and  the  desired  state. 

•  Docmnent  motivations  in  “Motivations”  section  of  the 
SPI  strategic  plan. 
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1  Identify  Current  and  Future  (Planned)  Improvement  Efforts 


3.7  Identify  Current  and  Future  (Planned) 

Improvement  Efforts 

Purpose  Identify  other  initiatives  the  organization  may  have  under 

way.  This  is  done  during  a  review  of  the  organizations  vi¬ 
sion,  business  plan,  and  past  improvement  efforts. 

Typically,  most  organizations  have  many  different  im¬ 
provement  efforts  under  way.  Often  these  initiatives  are 
un-coordinated  and  compete  with  each  other  for  scarce  re¬ 
sources.  If  an  organization  is  to  maximize  the  effectiveness 
of  its  investment  in  software  process  improvement,  it  must 
evaluate  all  of  the  initiatives  under  way  and  determine 
how  much  it  is  investing  in  each  one  and  in  total. 

Resistance  to  change  is  also  directly  correlated  to  the  total 
amount  of  change  required  of  individuals.  For  an  organiza¬ 
tion  to  get  the  best  results,  the  cumulative  impact  of  all  im¬ 
provement  efforts  should  not  be  overwhelming  to  anyone. 
The  results  from  the  baselining  activities  will  be  prioritized 
against  and  reconciled  with  the  existing  and  currently 
planned  initiatives. 

Objectives  Identify  all  existing  and/or  anticipated  improvement  ef¬ 

forts  in  this  organization,  either  internally  or  externally 
driven  (such  as  corporate  initiatives). 

Entry  Criteria  Initiatives  identified  from  a  business  plan  or  similar  sourc¬ 

es. 

Exit  Criteria  Other  initiatives  identified,  prioritized,  and  preferably  rec¬ 

onciled,  with  the  results  documented  in  the  SPI  strategic 
plan. 
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3.7  Identify  Current  and  Future  (Planned)  Improvement  Efforts 


Tasks 


Identify  all  existing  and/or  anticipated  improvement  ef¬ 
forts  in  this  organization,  either  internally  or  externally 
driven  (such  as  corporate  initiatives). 

Estimate  resource  investments  in  each  and  resources 
required  to  complete,  including  deplo5dng  the  resulting 
improvements  throughout  the  organization. 

Estimate  the  total  amount  of  resources  that  the  organi¬ 
zation  is  able  and  willing  to  commit  to  these  initiatives. 

Prioritize  the  unique  initiatives  based  on  resource  limi¬ 
tations  and  determine  what  areas  the  organization  is 
willing  to  apply  resoimces  to  and  how  many  resources  it 
is  willing  to  apply. 

Document  the  results  in  related  initiatives  identified  in 
“Improvement  Agenda”  section  of  the  SPI  strategic  plan 
(see  Appendix  B.O  on  page  185). 
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Finalize  Roles  and  Responsibilities  of  the  Various  Infrastructure  Entities 


3.8 


Finalize  Roles  and  Responsibilities  of  the 
Various  infrastructure  Entities 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


Initial  charters,  along  with  a  definition  of  the  roles  and  re¬ 
sponsibilities  of  the  infrastructure,  may  now  be  outdated. 
For  those  going  through  the  IDEAL  cycle  for  the  first  time, 
you  should  now  have  a  lot  more  knowledge  about  what  SPI 
is  and  what  is  needed  to  make  it  successful.  It  would  be 
beneficial  to  review  the  roles  and  responsibilities  that  you 
initially  defined  for  your  infrastructure  and  make  any  nec¬ 
essary  adjustments.  For  those  who  are  reentering  the  Es¬ 
tablishing  phase  from  a  previous  cycle  through  the  IDEAL 
model,  you  should  have  lessons  learned  that  you  may  want 
to  apply  to  the  roles  and  responsibilities  defined  for  the  in¬ 
frastructure. 

This  activity  may  repeat  some  of  the  work  done  in  the  Ini¬ 
tiating  phase  (page  11).  Sometimes  this  repetition  is  not 
needed,  but  often,  the  MSG  has  different  members  than 
those  who  set  up  the  SPI  program,  and  they  will  need  to 
cover  some  of  the  same  topics  to  develop  their  own  under¬ 
standing  and  strategy.  When  this  step  is  entered  as  a  result 
of  a  subsequent  cycle  through  the  IDEAL  model,  these  top¬ 
ics  should  be  reviewed  at  a  minimum. 

•  Finalize  roles  and  responsibilities  for  the  SEPG,  MSG, 
and  any  other  SPI  management  and  coordination 
groups. 

•  Define  typical  roles  and  responsibilities  for  TWGs  in 
terms  of  their  responsibilities,  authority,  reporting  re¬ 
quirements,  etc. 

•  Infrastructures  charters  available. 

•  Action  planning  activity  launched. 

Roles  and  responsibilities  defined  and  documented  in  the 
“Organization”  section  of  the  SPI  strategic  plan. 
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3.8 


Tasks 


The  Establishing  Phase 

Finalize  Roles  and  Responsibilities  of  the  Various  Infrastructure  Entities 


•  Define  roles  and  responsibilities  for  the  MSG,  SEPG, 
TWGs,  etc.  (or  extract  from  their  charter). 

•  Document  roles  and  responsibilities  in  the  “Organiza¬ 
tion”  section  of  the  SPI  strategic  plan. 
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Prioritize  Activities  and  Develop  Improvement  Agenda 


3.9 

Prioritize  Activities  and  Develop  Improvement 

Agenda 

Purpose 

The  baselines,  particularly  the  maturity  baseline,  typically 
identify  issues  and  provide  recommendations  based  on  a 
much  broader  consensus  than  may  have  been  available  be¬ 
fore.  These  issues  and  recommendations  serve  to  provide 
some  guidance,  and  often,  a  prioritization  of  actions. 

Publicly  document  an  objective  approach  to  deciding  which 
of  the  many  competing  SPI  recommendations  and  actions 
will  be  launched  and  funded.  This  approach  will  be  depen¬ 
dent  on  the  business  needs  of  the  organization.  This  proce¬ 
dure  will  be  used  whenever  new  ideas  are  added  to  the  list 
of  actions  awaiting  resources. 

Objectives 

Define  criteria  for  selection  of  SPI  projects. 

Entry  Criteria 

Prioritization  criteria  developed  from  key  business  issues 
has  been  defined. 

Exit  Criteria 

Criteria  for  selection  of  SPI  projects  defined  and  document¬ 
ed  in  the  SPI  “Improvement  Agenda”  section  of  the  SPI 
strategic  plan. 

Tasks 

•  Define  criteria  to  be  used  to  select  improvement  action 
items  from  a  list  and  launch  them. 

•  Define  a  process  to  apply  those  criteria. 

•  Define  a  process  to  add  new  improvement  actions  and  to 
remove  outdated  improvement  actions  from  the  pend¬ 
ing  list. 

•  Dociiment  the  criteria  in  the  “Improvement  Agenda” 
section  of  the  SPI  strategic  plan. 
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3.10  Reconcile  the  Existing/Planned  Improvement 

Efforts  with  the  Baseline  Findings  and 
Recommendations 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


Tasks 


The  results  of  the  baselines  should  be  incorporated  into  the 
SPI  strategic  action  plan  and  reconciled  with  all  other  ex¬ 
isting  and  /  or  planned  improvement  efforts.  This  will  re¬ 
sult  in  one  single  strategy  dealing  with  all  software  process 
improvement  actions  and  all  related  improvement  efforts 
affecting  the  same  groups  of  people. 

•  Incorporate  baseline  results  into  the  SPI  strategic  plan. 

•  Reconcile  baseline  results  with  all  other  existing  and/or 
planned  software  improvement  activities. 

•  Baselining  activities  completed  and  findings  and  recom¬ 
mendations  report  available. 

•  Other  existing  or  planned  improvement  efforts  identi¬ 
fied. 

•  SPI  strategic  action  plan  draft. 

•  A  single  coherent  strategy,  incorporating  baseline  re¬ 
sults  and  other  improvement  efforts. 

•  Matrix  relating  baseline  recommendations  and  issues 
to  other  existing/planned  activities. 

•  Reconciled  plan. 

•  Review  the  results  of  the  baseline  efforts. 

•  Build  a  matrix  relating  recommendations  fi'om  the 
baselines  to  existing  and  planned  activities. 

•  Document  motivations  to  improve. 

•  Review/revise  goals  as  appropriate. 
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3.11  Transform  the  General  Software  Process 


Improvement  (SPI)  Goals  to  Specific  Measurable 
Goals 


Purpose 


Objectives 
Entry  Criteria 


Exit  Criteria 
Tasks 


Now  that  the  results  of  the  baseline  activities  have  been 
reconciled,  sufficient  data  should  be  available  to  take  the 
general  long-term  and  short-term  goals  developed  in 
Step  1.8  on  page  49  and  make  them  specific.  This  is  done  by 
incorporating  the  measurement  of  the  current  state  of 
those  goals  and  defining  an  aggressive  but  achievable  im¬ 
provement  in  those  measures. 

For  example,  one  general  goal  could  have  been  to  make 
software  projects  more  predictable  in  terms  of  cost  and 
schedule.  The  measurement  baseline  established  that  80 
percent  of  current  projects  exceed  their  original  cost  and 
schedule  estimates  by  more  than  25  percent.  The  trans¬ 
formed  goal  could  be  to  improve  that  measure  such  that  80 
percent  of  all  projects  complete  within  10  percent  of  their 
original  estimates,  (adjusted  for  changes  of  scope  along  the 
way)  within  2  years. 

The  above  is  an  example  of  how  to  transform  a  general 
business  goal  into  a  specific  measurable  process  improve¬ 
ment  goal. 

Transform  all  general  goals  into  specific,  measurable  goals. 

•  Measurement  baseline  complete. 

•  High  level  goals  defined  during  the  Initiating  phase 
available. 

Measurable  goals  finalized  in  SPI  strategic  plan. 

Transform  the  goals  into  measurable  specific  improvement 
goals. 
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3.12 


Create/Update  the  SPI  Strategic  Plan 


Purpose 


Objectives 
Entry  Criteria 


Exit  Criteria 
Tasks 


Now  that  all  sections  of  the  SPI  strategic  action  plan  are 
ready,  the  plan  has  been  reconciled  with  the  baseline  re¬ 
sults,  and  the  goals  transformed,  the  plan  has  to  be  put  to¬ 
gether,  edited,  and  finalized. 

Finalize  the  SPI  strategic  plan. 

•  All  sections  of  the  strategic  action  plan  completed  or  in¬ 
puts  finalized. 

Complete  SPI  strategic  plan  written. 

•  Merge  the  various  sections  developed  during  previous 
steps  in  this  process. 

•  Edit,  resolving  inconsistencies,  etc. 

•  Prepare  final  draft  for  review. 
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3.13  Build  Consensus,  Review,  and  Approve  the  SPI 

Strategic  Plan  and  Commit  Resources  to  Action 

Purpose  The  action  plan  will  be  no  good  if  it  is  built  in  a  vacuum  and 

only  a  small  group  believes  in  it.  To  be  useful,  it  has  to  be 
“sold,”  and  consensus  has  to  be  developed. 

The  action  plan  that  is  developed  needs  to  be  communicat¬ 
ed  to  the  organization.  You  are  expecting  the  components 
and  personnel  within  the  organization  to  make  this  plan 
work;  it  is  only  proper  that  you  communicate  what  is  in  it 
and  expected  of  them. 

Objectives  .  Approve  SPI  strategic  action  plan. 

•  Build  consensus  and  commitment  to  the  plan. 

Entry  Criteria  Completed  draft  plan  ready. 

Exit  Criteria  SPI  action  plan  finalized  and  approved. 

T  asks  .  Present/review  the  plan  at  all  levels  of  the  organization. 

•  Collect  comments  and  suggestions  and  resolve  conflict¬ 
ing  ideas. 

•  Incorporate  all  changes  and  have  all  senior  line  manag¬ 
ers  as  well  as  the  organization’s  senior  manager  sign 
the  plan. 

•  Publicize  the  plan  (send  a  copy  to  everyone  in  the  orga¬ 
nization). 
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3.14 


Form  the  Technical  Working  Group  (TWG) 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


For  improvements  that  take  more  than  a  couple  of  days  of 
one  person’s  time  and  affect  several  people,  a  team  ap¬ 
proach  usually  works  best.  The  team  should  be  composed  of 
volunteers  from  the  target  audience  (those  who  will  ulti¬ 
mately  adopt  the  process  improvement)  who  are  enthusias¬ 
tic  about  working  on  the  improvement.  This  group  of  people 
can  be  identified  during  the  baselining  portion  of  the  activ¬ 
ity.  In  the  recommendation-generating  step  of  the  matmity 
baseline,  people  can  be  asked  to  rank  the  alternatives  by 
their  own  enthusiasm.  When  a  particular  solution  area  is 
decided  upon,  these  people  can  be  contacted  to  commit  to 
the  project  “for  real.” 

Build  a  team  from  people  with  diverse  backgrounds  who  all 
have  a  stake  in  the  area  of  improvement. 

•  TWG  charter  and  draft  tactical  action  plan  from  MSG/- 
SEPG. 

•  High-level  process  descriptions  from  process  baselining 
step. 

•  Process  maturity  issues  from  matmity  basehning  step. 

•  Related  recommendations  and  “low-hanging  fruit”  from 
maturity  baselining  step. 

•  Key  process  metrics  from  metrics  baselining  step. 

TWG  established. 


•  Assign  MSG  sponsorship  responsibility  for  the  TWG  to 
one  MSG  member.  The  TWG  needs  one  person  on  the 
MS(j  to  act  as  primary  sponsor  and  advocate.  This  per¬ 
son  is  usually  the  process  owner  of  the  particular  area 
the  TWG  is  going  to  be  improving.  The  MSG  sponsor 
will  have  the  responsibility  to  communicate  issues 
about  the  TWG  activities  to  other  MSG  members  and  to 
give  feedback  to  the  TWG  from  the  MSG. 
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3.14  Form  the  Technical  Working  Group  (TWG) 


•  Assign  SEPG  liaison  responsibility  for  the  TWG  to  one 
SEPG  member.  The  SEPG  liaison 

•  acts  as  facilitator  or  “quality  advisor”  (see 
Scholtes,  Peter  R.,  The  TEAM  Handbook:  How  to 
Use  Teams  to  Improve  Quality)  to  the  TWG 

•  brings  the  data  from  the  baselining  steps  to  the 
other  TWG  members 

•  facilitates  the  flow  of  information  between  the 
various  people  and  groups  involved  in  process 
improvement,  such  as  between  the  TWG  and  the 
MSG  and  other  organizations,  and  among  the 
team  members  themselves. 

•  acts  as  the  surrogate  leader,  when  the  TWG  is 
beginning  its  work,  until  the  designated  or 
agreed  upon  TWG  leader  can  take  over 

•  Get  the  enthusiastic  people  from  the  organization  to 
work  on  the  team.  D\uing  the  recommendations  step, 
people  prioritize  improvements  based  on  their  enthusi¬ 
asm  for  the  improvement  area.  No  commitment  is  im¬ 
plied  at  that  time,  however.  Now  that  the  improvement 
areas  have  been  identified,  the  same  people  should  be 
contacted  to  see  if  they  are  still  interested.  Their  com¬ 
mitment  and  the  commitment  of  their  managers  must 
be  secured  for  them  to  work  on  the  team. 

•  Plan  and  conduct  a  team  kickoff  meeting  with  sponsor 
attending.  The  first  team  meeting  should  be  conducted 
with  all  TWG  members,  the  SEPG  liaison,  and  the  MSG 
sponsor  present  to  officially  start  up  the  TWG.  Materi¬ 
als  should  have  been  exchanged  before  this  time,  but 
this  is  the  official  hand-off  of  the  draft  charter  and  draft 
tactical  action  plan  from  the  MSG  to  the  TWG.  For  oth¬ 
er  activities  that  should  go  on  during  the  first  meeting, 
refer  to  The  TEAM  Handbook. 

•  Set  up  initial  schedule  for  TWG.  The  TWG  should  set  up 
an  initial  schedule  of  working  meetings  to  get  through 
the  next  two  or  three  steps. 
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4.0  The  Acting  Phase 


Overview  The  Acting  phase  is  where  the  improvements  are  devel¬ 

oped,  put  into  practice,  and  deployed  across  the  organiza¬ 
tion.  The  various  improvements  that  the  working  groups 
have  developed  are  complete  and  their  value  will  be  “prov¬ 
en”  to  the  organization  by  piloting  them.  The  management 
steering  group  (MSG)  and  the  software  engineering  process 
group  (SEPG)  will  be  managing  and  supporting  the  devel¬ 
opment,  piloting,  and  deplo3rment  of  the  improvements; 
their  tasks  are  explained  further  in  Section  6.0  on 
page  141. 

The  Acting  phase  links  the  mission  of  the  SPI  program  to 
improve  processes  and  the  mission  of  the  development  or¬ 
ganization  to  produce  products.  It  is  the  culmination  of  the 
SPI  efforts  to  this  point. 

To  decide  on  and  introduce  improvement,  the  current  orga¬ 
nizational  practices,  used  in  creating  the  software  work 
products,  must  be  researched  and  evaluated  so  that  they 
are  fully  understood  and  documented.  It  is  also  important 
to  identify  the  effects  of  change  in  a  particular  area;  these 
effects  should  be  identified  as  early  as  possible  so  that  they 
can  be  dealt  with  in  a  timely  fashion. 

To  help  understand  the  current  practices,  techniques  are 
available  to  model  and  assess  the  current  practice.  These 
will  define  and  document  the  “as  is”  state.  To  determine  the 
areas  for  improvement,  the  “as  is”  candidate  processes 
must  be  screened  and  evaluated.  After  this  evaluation  and 
creation  of  the  “as  is”  state,  the  organization  needs  to  de¬ 
fine  a  “to  be”  state  and  select  fi*om  appropriate  solution 
candidates  to  achieve  the  “to  be”  state.  After  this  evalua¬ 
tion  and  selection,  informed  decisions  can  be  made  for  se- 
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The  Acting  Phase 


Purpose 


lecting  the  candidate  technology  to  be  used  for  the  improve¬ 
ment.  This  activity  identifies  a  “to  be”  state. 

The  Acting  phase  is  the  point  in  time  where  you  are  asking 
the  organization  to  change  the  way  things  were  previously 
done.  Selecting  the  proper  method  to  achieve  the  “to  be” 
state  is  important  to  the  overall  success  of  the  Acting 
phase. 

This  step  is  the  process  in  which  technical  working  groups 
(TWGs)  develop  specific  improvements  to  specific  process¬ 
es.  There  are  two  basic  approaches  to  designing  solutions: 

1.  Focus  on  solving  specific  problems  (problem-centered 
approach). 

2.  Incrementally  improve  a  particular  process  (process- 
centered  approach). 

In  the  first  approach,  the  TWGs  focus  on  a  specific  problem 
and  develop  a  solution  using  pilot  projects  to  validate  and 
refine  the  solution.  In  the  second  approach,  the  TWGs  focus 
on  a  particular  process  and  develop  incremental  refine¬ 
ments  to  it,  again  using  pilot  projects  to  test  out  the  refine¬ 
ments.  There  will  probably  be  several  of  these  TWGs  run¬ 
ning  simultaneously.  This  process  represents  the  typical 
TWG  life  cycle  for  producing  process  improvements,  and  so 
is  written  from  this  point  of  view.  The  SEPG  and  MSG  are 
described  primarily  in  Section  6.0  on  page  141,  which  runs 
in  parallel  with  this  step. 

The  purpose  of  this  phase  is  to  develop  improvements  and 
solutions  to  the  process  issues  found  during  the  baselining 
phase.  The  key  processes  and/or  problems  discovered  dur¬ 
ing  the  Diagnosing  phase  have  been  prioritized  and  select¬ 
ed  during  the  Establishing  phase;  the  process  described  in 
this  step  is  where  the  actual  work  of  providing  refinements 
to  the  key  processes  or  fixing  those  problems  is  performed. 
The  results  of  this  work  will  be  turned  over  to  the  SEPG 
and  MSG,  and  to  project  development  teams  to  finally  in¬ 
corporate  into  their  project  execution. 
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Objectives 


Education/Skills 


•  Develop  or  refine  the  software  development  processes 
as  prioritized  in  the  action  plan. 

•  Bring  line  organizations  “up-to-speed”  on  the  improve¬ 
ments)  they  will  be  using. 

•  Integrate  the  process  improvements  with  new  or  exist¬ 
ing  project  development  plans. 

•  Monitor  and  support  the  line  organizations  as  they  use 
the  new  or  modified  processes. 

The  TWO  will 

•  plan  the  improvement  project 

•  understand  the  process,  including  customers 
needs,  and  develop  refinements  to  it  (process 
orientation) 

•  investigate  the  problem  and  develop  a  solution 
(problem  orientation) 

•  pilot  a  solution,  validate  and  refine  it 

•  develop  rollout  strategy  and  plan  template  for  applying 
the  solution 

•  evaluate  the  solution  in  use 

•  re-iterate  the  cycle  for  further  improvements 

Training  and  skill  development  for  the  Acting  phase  is 

shown  in  the  following  table. 


Education/Skills 

MSG 

SEPG 

TWG 

Line 

Managers 

Practitioners 

New/modified  process 

X 

X 

X 

X 

Change  management 

X 

X 

X 

X 

X 

Team  development 

X 

X 

X 

Problem  solving  techniques 

X 

X 
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Commitment 


Communication 


The  SEPG  must  keep  working  with  both  the  MSG  and  the 
line  organizations  to  ensure  that  the  commitment  to  install 
and  institutionalize  the  change  exists  and  is  strong 
enough.  The  MSG  must  secure  the  commitment  of  the  de¬ 
velopment  organization  and  cascade  this  commitment 
down  to  the  line  organizations.  The  line  organization  man¬ 
ager  must  secure  the  commitment  of  the  project  members 
to  implement  the  change  and  get  commitment  from  the 
SEPG  for  support  during  the  transition. 

Since  the  TWG  receives  its  charter  from  the  MSG,  overall 
commitment  to  the  TWG  charter  is  assumed.  However,  ad¬ 
ditional  sponsorship  and  deeper  commitment  for  the  specif¬ 
ic  changes,  staffing,  and  commitments  of  pilot  projects,  and 
building  the  capability  of  the  organization  to  receive  the 
TWG  products,  is  needed.  Commitment  should  come  from 
several  distinct  groups: 

Senior  management:  The  TWG  must  periodically  refresh 
the  commitment  of  the  MSG  through  progress  reports,  clar¬ 
ification  on  issues  and  goals,  and  involvement  in  organiza¬ 
tion-wide  decisions. 

Middle  management:  The  TWGs  must  gain  commitment 
from  middle  managers  for  their  own  time  and  the  time  re¬ 
quired  from  pilot  projects  to  develop  solutions. 

Line  management  and  practitioners:  The  TWGs  will  need 
to  establish  the  commitment  and  consensus  of  those  who 
will  be  implementing  the  process  improvement  as  part  of 
their  product  development  projects.  This  requires  getting 
early  feedback  and  continuing  to  elicit  input  and  gain 
agreement  from  the  various  projects  on  the  content  of  the 
process  improvement  as  well  as  how  it  is  to  be  initiated  and 
supported. 

The  TWGs  have  to  communicate  with  project  personnel, 
project  management,  subject  matter  experts,  along  with 
the  SEPG  and  MSG.  In  addition,  the  TWG  will  be  working 
with  solution  providers  to  get  the  best  solution  in  the  orga¬ 
nization. 
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Entry  Criteria 


Specific  communications  include  the  following: 

•  TWG  to  SEPG:  primarily  status  updates  and  requests 
for  information  and  assistance. 

•  TWG  to  MSG:  primarily  status  updates  and  requests  for 
resource-level  approvals;  occasionally  requests  for  arbi¬ 
tration/decisions  affecting  the  organization  that  the 
TWG  or  the  SEPG  cannot  make. 

•  TWG  to  target  groups:  The  TWG  must  elicit  require¬ 
ments  and  feedback  from  the  eventual  target  groups  to 
ensure  that  the  needs  of  these  groups  are  met  by  the 
eventual  solution.  In  addition,  the  TWG  should  solicit 
interest  in  pilot  participation  from  the  affected  target 
groups. 

•  TWG  to  pilots:  For  the  TWG  to  get  the  appropriate  feed¬ 
back  to  refine  the  process  improvement  solution,  signif¬ 
icant  commtmication  is  required  to  ensure  the  proper 
execution  of  the  pilot  project. 

The  SEPG  will  be  primarily  responsible  for  insuring  tech¬ 
nology  transition  of  the  change  into  the  line  orgeinization. 
The  MSG  and  SEPG  communicate  the  rollout  strategy  and 
plan  and  specific  process  changes  to  the  development  orga¬ 
nization.  The  SEPG  works  closely  with  the  line  organiza¬ 
tion  to  integrate  the  changes  into  the  line  organization’s 
plans  and  activities. 

•  TWG  charter  and  tactical  action  plan  template  fi'om 
MSG/SEPG. 

•  Process  maturity  issues  from  the  Establishing  phase. 

•  Related  recommendations  and  “low-hanging  finiit” 
(quick-fix,  quick-return  improvement  projects)  from 
baselining  step(s). 

•  High-level  process  descriptions  fi'om  process  baselining 
step(s). 
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Exit  Criteria 


•  Measurable  goals  identified  during  the  Establishing 
phase. 

•  Key  process  metrics  from  metrics  baselining  step. 

•  The  rollout  strategy  and  plan  is  fully  executed,  or  being 
executed. 

•  Solution  packaged  properly  and  turned  over  to  SEPG. 

•  Long  term  support  has  been  arranged  for. 

•  The  process  improvement  has  begun  to  be  institutional¬ 
ized  in  the  line  organization. 

See  Figure  4-1  on  page  99  for  a  pictorial  representation  of 

the  tasks  associated  with  the  Acting  phase  of  the  IDEAL 

model. 
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Figure  4-1 :  Process  Flow  for  Acting  Phase 
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4.0  The  Acting  Phase 


Tasks 


The  tasks  for  the  Acting  phase  are  shown  in  the  table  be¬ 
low. 


Tasks 

Page 

Number 

4.1;  Complete  Tactical  Plan  for  Technical  Working  Group  (TWG) 

101 

4.2;  Develop  Solutions 

103  ; 

4.3;  Pilot  Potential  Solutions 

107 

4.4;  Select  Solution  Providers 

108 

4.5;  Determine  Long-Term  Support  Needs 

110 

4.6;  Develop  Rollout  Strategy  and  Plan  Template 

111 

4.7;  Package  the  Improvement  and  Turn  Over  to  the  Software  Engineering  Process 
Group  (SEPG) 

112 

4.8;  Disband  the  TWG 

114  1 

4.9;  Rollout  Solution 

115 

4.10;  Transition  to  Long-Term  Support 

126 

_ 1 
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4.0  The  Acting  Phase 

4.1  Complete  Tactical  Plan  for  Technical  Working  Group  (TWG) 


4.1 


Complete  Tactical  Plan  for  Technical  Working 
Group  (TWG) 


Purpose 


Objectives 


Entry  Criteria 
Exit  Criteria 
Tasks 


The  purpose  of  this  step  is  to  complete  a  tactical  plan  from 
a  template  that  is  supplied  to  the  TWG  by  the  MSG.  The 
completed  plan  will  be  approved  by  the  MSG.  The  team’s 
early  efforts  should  be  focused  on  narrowing  the  scope  of 
the  charter  to  the  specific  improvement  on  which  they  will 
work. 

Defining  the  scope  of  the  effort  is  a  very  important  activity. 
Too  many  times  improvement  teams  have  taken  on  too  big 
a  scope  and  have  failed  to  complete  the  effort.  A  guideline 
for  determining  the  scope  of  the  TWGs  project  should  be 
something  that  can  be  accomplished  in  6  to  9  months  or 
less.  Improvement  teams  are  trying  to  strike  a  balance  be¬ 
tween  showing  early  results  to  the  organization  and  com¬ 
ing  up  with  the  best  solution.  There  is  nothing  wrong  with 
taking  a  two  or  three  step  approach  to  developing  an  im¬ 
provement,  intermediate  benefits  can  be  shown  along  the 
way. 

•  Complete  the  tactical  action  plan  sections  not  specified 
by  the  MSG,  and  fill  in  other  areas  of  the  plan. 

•  Review  and  narrow  the  scope  of  the  project,  if  necessary, 
to  something  that  can  be  done  in  a  relatively  short 
amoimt  of  time.  (6-9  months) 

Tactical  plan  template  from  MSG. 

Tactical  plan  approved  by  MSG. 

•  Review  draft  tactical  plan  with  MSG  sponsor  and  SEPG 
liaison. 

•  Review  data  from  baselining  phase  with  SEPG  liaison. 

•  Develop  task  sorting  and  selection  criteria. 
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4.0  The  Acting  Phase 

4.1  Complete  Tactical  Plan  for  Technical  Working  Group  (TWG) 


•  Explore  problem  area  to  get  preliminary  directions  for 
the  team. 

•  Create  work  breakdown  structure  (WBS)  for  the  TWG. 

•  Organize  WBS  tasks  into  a  schedule  with  milestones 
and  deliverables. 

•  Review  and  refine  the  tactical  plan  with  MSG  sponsor 
and  SEPG  liaison. 
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4.2  Develop  Solutions 


4.2  Develop  Solutions 


Purpose  This  is  the  step  where  solutions  to  the  process  issues  found 

during  the  Diagnosing  phase  are  developed.  The  purpose  of 
this  task  is  to  create  solutions  to  the  problems  or  processes 
that  the  organization  has  determined  are  necessary  to 
meet  the  business  needs  of  the  organization. 

The  solution  selected  should  be  compatible  with  the  organi¬ 
zation’s  culture  so  that  it  will  be  readily  accepted  and  easi¬ 
er  to  institutionalize. 

Objectives  .  Investigate  alternative  solutions  to  process  issues  dis¬ 

covered  during  the  baselining  activity. 

Select  solution  that  best  fits  the  business  needs  and  culture 
of  the  organization. 

Entry  Criteria  .  Baselining  activity  completed. 

•  TWGs  established. 

•  TWGs  trained. 

•  Final  briefing  firom  baselining  activity  available. 

•  Final  Findings  and  Recommendations  Report  available. 

•  Policies,  procedures,  guidelines,  etc.  available. 

Exit  Criteria  .  Solutions  selected  and  documented. 

•  Plan  template  for  piloting  the  solution  developed. 

Subtasks  The  subtasks  for  this  task  are  shown  in  the  table  below. 


Subtask 

Page 

Number 

4.2.1:  Refine  the  Process  (Process-Centered  Approach) 

104 

4.2.2:  Analyze  and  Fix  the  Problem  (Problem-Centered  Approach) 

106 
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4.0  The  Acting  Phase 

4.2  Develop  Solutions 

4.2.1  Refine  the  Process  (Process-Centered  Approach) 


4.2.1  Refine  the  Process  (Process-Centered  Approach) 


Purpose 


Objectives 


Entry  Criteria 


Tasks 


The  process-centered  approach  deals  with  understanding  a 
specific  key  process  identified  during  the  baselining  phase 
and  applying  incremental  refinements  to  the  process.  This 
approach  is  useful  for  achieving  long-term  improvements 
in  the  process.  However,  because  of  the  immediate  pres¬ 
sures  and  uncertainties  typical  of  lower  level  maturity  or¬ 
ganizations,  it  is  difficult  to  maintain  this  focus  in  such  or¬ 
ganizations.  Sustaining  a  process-centered  approach  re¬ 
quires  strong  management  commitment  and  organization¬ 
al  momentum  and  enthusiasm.  Even  with  the  requirement 
for  strong  management  commitment,  the  problem-centered 
approach  is  recommended  for  first-time  process  improve¬ 
ment  programs. 

•  Understand  the  existing  process. 

•  Refine  the  existing  process  to  eliminate  errors  and  re¬ 
duce  variations. 

•  Set  up  a  continuous  improvement  cycle  for  the  process. 

•  TWG  formed  and  trained. 

•  Process  baseline  and  maturity  issue  data  from  the  base¬ 
lining  phase. 

•  Tactical  action  plan. 

•  Identity  process  stakeholders  and  understand  their 
needs. 

•  Determine  current  process  scope  /  boundaries  /  context. 

•  Describe  the  desired  state  of  the  process  (the  “to  be”). 

•  Analyze  the  gap  between  the  “as  is”  and  “to  be”  states. 

•  Create  refined  process. 

•  Determine  process  modeling  objectives. 

•  Model  the  new  process. 


104 


CMU/SEI-96-HB-001 


4.0  The  Acting  Phase 

4.2  Develop  Solutions 

4.2.1  Refine  the  Process  (Process-Centered  Approach) 

•  Specify  process  metrics. 

•  Implement  the  process. 

Exit  CritGria  Solution  components  identified:  process  descriptions,  pro¬ 

cedures,  metrics,  methods,  and  tools. 
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4.0  The  Acting  Phase 

4.2  Develop  Solutions 

4.2.2  Analyze  and  Fix  the  Problem  (Problem-Centered  Approach) 


4.2.2  Analyze  and  Fix  the  Problem  (Problem-Centered 

Approach) 


Purpose 


Objectives 
Entry  Criteria 


Tasks 


Exit  Criteria 


The  problem-centered  approach  is  distinct  from  the  pro- 
cess-centered  approach  in  that  it  is  more  useful  for  easily 
identifiable  problems  and  can  provide  results  faster  than 
the  process-centered  approach.  When  problems  become 
complex  or  solutions  unwieldy,  however,  the  results  of  the 
problem-centered  approach  are  often  overtaken  by  other 
problems  that  crop  up  when  early  problems  are  fixed.  Be¬ 
cause  it  will  get  the  momentum  up  and  keep  enthusiasm 
alive,  the  problem-centered  approach  is  useful  for  getting  a 
software  process  improvement  (SPI)  program  started. 
However,  the  process-centered  approach  will  be  more  use¬ 
ful  for  long-term  results. 

Develop  solutions  to  specific  problems. 

•  Problem  description  and  issue  data  from  the  baselining 
phase. 

•  Tactical  action  plan. 

•  State  the  problem. 

•  Define  solution  goals. 

•  Identify  constraints. 

•  Analyze  the  problem. 

•  Generate  and  select  alternatives  to  address  problem. 

•  Define  solution  metrics. 

•  Select  best  solution  from  alternatives  discovered. 

Solution  components  identified:  process  descriptions,  pro¬ 
cedures,  metrics,  methods,  and  tools. 
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4.3  Pilot  Potential  Solutions 


4.3 


Pilot  Potential  Solutions 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


Tasks 


Pilot  projects  are  used  to  test  out  the  solutions  in  both  the 
process-centered  and  problem-centered  approaches.  The 
solutions  will  require  some  tailoring  and  refinement  to  fit 
them  into  projects  across  the  organization,  and  the  pilots 
will  help  determine  the  tailoring  needs  and  guidelines  for 
the  rest  of  the  organization.  Several  pilots  may  be  run  for  a 
solution,  and  there  may  be  several  iterations  between  the 
solution  development  and  piloting  steps  to  get  the  solution 
ready  for  deployment  across  the  organization. 

•  Verify  the  solution  in  a  real  project  in  the  organization. 

•  Capture  lessons  learned  and  results  of  pilot  to  refine  the 
solution  and  the  installation  of  the  solution. 

Solution  components:  process  description,  procedures, 
metrics,  methods,  and  tools. 

Training  and  installation  needs  identified  and  planned. 
Completed  pilot. 

Pilot  project  completion  criteria  are  met. 

Lessons  learned  and  results  of  pilot  have  been  captured 
and  preserved  by  TWG. 

Develop  pilot  selection  and  completion  criteria. 

Identify  potential  pilot  projects. 

Select  pilot  project  team. 

•  Train  pilot  project  team. 

Install  solution  in  pilot  project. 

■  Execute  and  monitor  pilot  project. 

Evaluate  results  of  pilot. 

Capture  lessons  learned  from  pilot. 
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4.4  Select  Solution  Providers 


4.4  Select  Solution  Providers 


Purpose  There  may  be  several  sources  of  support  for  the  process  im¬ 

provement  solution,  some  competing,  others  complementa¬ 
ry.  Solution  providers  can  be  internal  or  external  to  the  or¬ 
ganization,  and  solution  providers  could  be  the  TWG  or 
some  subset  of  the  TWG.  Given  the  organization’s  varying 
needs,  the  TWG  must  determine  the  best  source  for  provid¬ 
ing  the  solution.  During  this  phase  the  TWG  should  work 
closely  with  the  SEPG  to  use  established  and  vetted  solu¬ 
tion  providers. 

This  step  can  run  in  parallel  with  the  solution  creation 
steps.  The  solution  provider(s)  may  be  part  of  determining 
the  solution,  or  in  some  cases  the  selection  criteria  for 
choosing  providers  may  not  be  determined  until  well  into 
pilot  testing  the  solution.  When  several  tools  are  compet¬ 
ing,  the  TWG  must  establish  working  relationships  with 
various  vendors  to  get  the  best  solution  for  the  organiza¬ 
tion. 


Objectives 

Investigate  various  providers  of  solutions  and  their  track 
records  to  find  ones  that  best  match  the  needs  of  the  orga¬ 
nization,  both  short  and  long  term. 

Entry  Criteria 

TWG  has  selected  or  developed  a  solution  for  the  process  is¬ 
sue  at  hand. 

Exit  Criteria 

Designated  solution  provider(s)  for  the  solution  are  ready 
to  implement  and  provide  support. 

Tasks 

•  Obtain  contacts  for  potential  providers  of  solutions 
(from  SEPG). 

•  Contact  providers  and  arrange  briefing  sessions. 

•  Develop  selection  criteria  based  on  organization  needs 
and  range  of  possibilities  among  providers. 
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4.4  Select  Solution  Providers 


•  Narrow  down  the  set  of  providers  to  one  or  two  that  best 
meet  needs  and  are  ready  to  work  with  the  organiza¬ 
tion. 

•  Develop  contracts  with  solution  providers. 
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The  Acting  Phase 

Determine  Long-Term  Support  Needs 


4.5 


Determine  Long-Term  Support  Needs 


Purpose 


Objectives 


Entry  Criteria 
Exit  Criteria 


Tasks 


Long-term  solutions  will  require  long-term  support.  As  the 
solution  is  implemented  in  other  parts  of  the  organization, 
people  will  have  to  be  trained,  problems  may  crop  up,  and 
additional  tailoring  may  be  needed.  This  step  identifies  the 
requirements  for  long-term  support  in  terms  of  knowledge 
and  skills  required,  how  defects  are  fixed,  installation  and 
configuration  consulting,  etc.  The  improvement  should  be 
planned  to  last  for  a  few  years  (possibly  as  part  of  some 
larger  improvement  effort).  Ongoing  support  for  any  tools, 
methods,  classes,  materials,  etc.,  should  be  planned  in  par¬ 
allel  with  the  solution  development  step. 

•  Identify  long-term  support  needs  and  potential  sources 
for  support. 

•  Plan  internal  long-term  support  mechanisms. 

•  Secure  funding  for  long-term  support. 

List  of  recommended  support  providers  from  SEPG. 

•  Specific  support  provider(s)  chosen. 

•  Support  contracts  drafted. 

•  Work  with  support  providers  to  satisfy  needs  of  TWG 
and  pilot  solution. 

•  Refine  TWG  and  pilot  needs  to  enable  best  possible  sup¬ 
port  for  entire  organization. 
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4.6  Develop  Rollout  Strategy  and  Plan  Template 


4.6 


Develop  Rollout  Strategy  and  Plan  Template 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


Tasks 


Once  the  solution  has  been  developed  and  piloted,  and  the 
short-  and  long-term  support  needs  have  been  addressed, 
the  solution  will  be  ready  to  roll  out  to  the  organization. 
The  TWG  will  create  a  rollout  plan  template  that  gives 
guidance  to  the  development  projects  that  will  be  installing 
the  process  improvement.  The  plan  will  include 

•  what  training  they  need 

•  what  tools  and  methods  to  acquire 

•  installation  steps 

•  information  on  how  to  get  support,  etc. 

This  plan  will  be  used  as  a  template  by  the  project  to  inte¬ 
grate  with  their  own  project  plans  and  by  the  MSG  to  inte¬ 
grate  the  improvement  into  the  overall  organization  stra¬ 
tegic  pian  for  SPI. 

Create  rollout  plan  template  for  the  solution,  that  can  be 
customized  by  the  projects  during  their  rollout  of  the  solu¬ 
tion. 

•  Successful  pilot  implementation. 

•  Generic  rollout  plan  template. 

•  Tailoring  guidelines  for  developing  rollout  plan  from  the 
template. 

•  Guide  for  developing/integrating  rollout  plans. 

Rollout  plan  template  reviewed  and  approved  by  organiza¬ 
tion  receiving  solution. 

•  Using  generic  templates,  create  the  rollout  plan  for  this 
particular  solution. 

•  Review  rollout  plan  template  with  MSG/SEPG  for  ap¬ 
proval. 
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The  Acting  Phase 

Package  the  Improvement  and  Turn  Over  to  the  Software  Engineering  Process  Group  (SEPG) 


4.7  Package  the  Improvement  and  Turn  Over  to  the 

Software  Engineering  Process  Group  (SEPG) 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


Tasks 


During  solution  development  the  TWG  has  probably  devel¬ 
oped  several  intermediate  products  and  artifacts.  These 
must  be  collected  into  a  package  that  can  be  turned  over  to 
the  SEPG  for  long-term  maintenance  and  support.  (This 
task  will  be  much  simpler  if  the  TWG  is  doing  this  as  it  goes 
along.) 

•  Collect  and  clean  up  all  intermediate  products  and  arti¬ 
facts. 

•  Package  products  and  artifacts  for  archival  with  the 
SEPG. 

•  Process  improvement(s)  are  ready  for  distribution. 

•  Long-term  support  arrangements  are  in  place  and  solu¬ 
tion  providers  are  ready  to  implement  solutions 
throughout  the  organization. 

•  Artifacts  from  the  TWG  activities  are  available  (min¬ 
utes,  notes,  plans,  templates,  diagrams,  charts,  etc.). 

•  Training  and  support  is  available  for  the  organization. 

•  All  necessary  artifacts  are  collected  in  a  single  place  for 
long-term  support. 

•  SEPG  accepts  the  package. 

•  Identify  various  intermediate  products  and  artifacts  the 
team  has  produced. 

•  Collect  clean  copies  of  each  product  and/or  artifact. 

•  Write  descriptive  material  for  those  intermediate  prod¬ 
ucts  and  artifacts  for  which  it  is  needed. 

•  Organize  and  catalog  all  the  artifacts. 

•  Bind  the  products  and  artifacts  into  one  solution  pack¬ 
age. 
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4.7  Package  the  Improvement  and  Turn  Over  to  the  Software  Engineering  Process  Group  (SEPG) 


•  Review  solution  package  content  with  the  SEPG. 

•  Archive  the  package  with  the  SEPG,  adding  to  its  data¬ 
base  of  process  improvement  information  and  beginning 
the  maintenance  process  on  the  solution  package. 
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Disband  the  TWG 


4.8  Disband  the  TWG 

Purpose  As  a  final  task,  the  TWG  should  also  do  a  final  lessons 

learned  report  that  will  go  to  the  SEPG  and  MSG  to  help 
improve  the  process  for  running  and  managing  TWGs  dur¬ 
ing  solution  development.  The  TWG  has  now  completed  its 
tasks. 

A  reward  of  some  type  given  to  the  team  for  accomplishing 
its  work  is  a  strong  show  of  sponsorship  for  SPI  and  an  item 
for  communication  to  the  rest  of  the  organization. 

Finally,  the  team  should  celebrate  what  it  has  accom¬ 
plished. 

Objectives  •  Gather  lessons  learned  from  this  effort. 

•  Celebrate  the  accomplishments  of  this  team. 

Entry  Criteria  All  improvements  packaged  and  accepted  by  the  SEPG  for 

long-term  support. 

Exit  Criteria  ♦  Lessons  learned  report  delivered  to  SEPG. 

•  All  team  members’  efforts  recognized  and  rewarded. 

Tasks  .  Review  the  improvement  project.  Gather  lessons 

learned  from  the  TWG  to  improve  the  process  of  improv¬ 
ing  processes. 

•  Celebrate  the  completion  of  the  activity. 

•  Dissolve  the  team. 
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Rollout  Solution 


4.9 


Rollout  Solution 


Purpose  The  purpose  of  this  step  is  to  install  the  proven  solution 

across  the  organization.  The  solution  has  been  developed 
and  proven  by  pilot  testing  with  a  project.  Now  the  solution 
needs  to  be  installed  across  the  organization. 

Objectives  Install  solution  across  the  organization. 


Entry  Criteria  •  A  rollout  strategy  and  plan  has  been  created  and  ap¬ 

proved  by  the  MSG  and  the  development  organization’s 
senior  management  (it  helps  if  these  are  same). 

•  Specific  process  improvement  materials  are  ready  for 
development  teams  to  use. 

•  Training  and  ongoing  support  has  been  arranged  for 
process  improvement  solution. 

Exit  Criteria  Solution  installed  across  the  organization. 

Subtasks  The  subtasks  for  this  task  are  shown  in  the  table  below. 


Subtask 


Page 


4.9.1 :  Brief  Entire  Organization 
4.9.2:  Refine  Roilout  Strategy  and  Plan 
4.9.3:  Brief  Project 

4.9.4:  Tailor  Project  Rollout  Strategy  And  Plan 
4.9.5:  Train  Project 
4.9.6:  Install  Improvement 
i  4.9.7:  Evaluate  Deployment 


Number 


116 

Tl? 

Ti? 

Ti? 

120 

124 
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4.9  Rollout  Solution 

4.9.1  Brief  Entire  Organization 


4.9.1 


Brief  Entire  Organization 


Purpose 


Objectives 


Entry  Criteria 


Tasks 


Exit  Criteria 


SEPG  and  MSG  process  owners  brief  the  development  or¬ 
ganization  on  the  change  and  the  strategy  for  implement¬ 
ing  the  change.  The  development  organization  should  have 
been  kept  informed  on  the  progress  of  the  working  group 
during  the  solution  development  phase.  The  purpose  of  this 
briefing  will  be  to  announce  to  the  organization  the  formal 
adoption  of  the  change  (or  set  of  changes),  explain  the  ra¬ 
tionale  for  adopting  the  change,  and  explain  the  strategy 
for  deploying  the  change  across  the  organization. 

The  MSG  process  owner  is  the  primary  sponsor  for  the 
change  and  will  give  (or  lead)  the  briefing  to  show  maxi¬ 
mum  support  for  the  changes. 

•  Inform  the  organization  about  any  changes  in  policy  be¬ 
cause  of  the  adoption  of  process  improvement(s). 

•  Inform  the  organization  about  the  strategy  for  adoption, 
the  benefits  of  the  change,  and  the  linkage  to  the  orga¬ 
nization’s  business  goals  and  needs. 

•  Solution  has  been  successfully  piloted. 

•  Briefing  kit/information  completed. 

•  Deployment  strategy  completed. 

•  Plan  and  schedule  briefings.  The  briefings  should  be 
planned  and  scheduled  to  cover  the  entire  organization. 

•  Conduct  briefings. 

•  Gather  feedback  from  briefing  participants. 

•  Revise  future  briefings  based  on  feedback. 

•  Organization  briefing  completed. 

•  Lessons  are  learned  from  the  organization  on  the  de¬ 
ployment  strategy. 
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4.9.2  Refine  Rollout  Strategy  and  Plan 


4.9.2 


Refine  Rollout  Strategy  and  Plan 


Purpose 


Objectives 


Entry  Criteria 


Tasks 


Exit  Criteria 


Based  on  feedback  from  individual  projects  and  the  line  or¬ 
ganization  as  a  whole,  the  SEPG  and  MSG  process  owners 

modify  the  rollout  strategy  and  plan  to  better  accommodate 

the  organization’s  needs. 

•  Clarify  and  refine  rollout  strategy  and  plan,  communi¬ 
cate  to  organization. 

•  Incorporate  lessons  learned  from  the  pilot  deployment. 

•  Feedback  has  been  provided  from  strategy  briefings 
with  the  entire  organization  to  modify  the  rollout  strat¬ 
egy  and  plan. 

•  Rollout  strategy  and  plan  template  completed. 

•  Gather  feedback  from  other  tasks  in  this  section. 

•  Distill  lessons  learned  and  desired  modifications  from 
feedback. 

•  Incorporate  lessons  learned  in  rollout  strategy  and 
plan. 

•  Implement  next  task  (or  same  task  on  next  proj ect)  with 
new  rollout  strategy  and  plan. 

•  Communicate  broad  changes  to  entire  organization. 

•  Rollout  strategy  and  plan  is  fully  refined.  (Refinement 
continues  in  parallel  with  the  other  tasks  in  this  phase.) 

•  Revised  rollout  strategy  and  plan  completed. 
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4.9  Rollout  Solution 

4.9.3  Brief  Project 


4.9.3  Brief  Project 


Purpose 


Objectives 


Entry  Criteria 


Tasks 


Exit  Criteria 


SEPG  and  MSG  process  owners  brief  individual  organiza¬ 
tion  projects  on  the  specifics  of  the  change  (what  it  is,  why 
it  is  needed,  why  they  are  to  do  it  at  this  specific  time,  etc.). 

More  detail  about  the  process  improvement  should  be  pro¬ 
vided  to  the  organization  project  at  the  point  when  it  will 
be  expected  to  adopt  the  change  (projects  will  probably 
adopt  at  different  times  and  rates). 

Describe  how  the  process  improvement  is  expected  to  fit 
into  the  project. 

•  Briefing(s)  of  the  entire  organization  have  been  com¬ 
pleted. 

•  Rollout  strategy  and  plan  template  completed. 

•  Plan  and  schedule  project  briefings. 

•  Tailor  briefing  to  specific  project  and  set  of  changes. 

•  Conduct  briefings. 

•  Gather  feedback  from  briefings  to  refine  deployment. 

Project  understands  need  for  change  and  content  of 
changes. 
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The  Acting  Phase 
Rollout  Solution 

Tailor  Project  Rollout  Strategy  And  Plan 


4.9.4 


Tailor  Project  Rollout  Strategy  And  Plan 


Purpose 


Objectives 


SEPG  and  project  managers  in  the  organization  fill  in  the 
rollout  strategy  and  plan  template  for  the  specific  changes 
to  be  integrated,  in  the  context  of  the  overall  line  organiza¬ 
tion’s  plan(s).  The  process  improvement  is  tailored  to  the 
project’s  environment  and  circumstances.  There  will  be  ad¬ 
ditional  tailoring  as  the  project  continues  to  use  the  im¬ 
provement. 

Tailor  the  process  improvement  plans  to  fit  the  project. 


Entry  Criteria  Project  briefings  completed. 


inputs 


Rollout  plan  template. 


Tasks 


Exit  Criteria 


Using  rollout  plan  template,  fill  in  appropriate  dates, 
resources,  costs,  names,  etc.,  specific  to  this  project’s  in¬ 
stallation. 

Review  the  tailored  rollout  plan  with  the  project,  get¬ 
ting  buy-in  from  affected  targets  for  implementation. 

Review  tailored  rollout  plan  with  MSG. 

Project  agreement  with  tailored  rollout  plan. 

Tailored  rollout  plan. 
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4.9.5  Train  Project 


Purpose  The  solution  developed  will  probably  require  new  skills  and 

knowledge  to  be  acquired  by  the  line  organization.  To  pro¬ 
vide  the  maximum  benefit  to  the  line  organization  mem¬ 
bers,  training  and  practice  must  be  integrated  into  the 
project  plans.  SEPG  and  line  organization  managers  ar¬ 
range  training  and  detailed  briefings  for  line  personnel  in 
new  process,  methods,  tools,  etc. 

Although  the  tasks  4.9.5  (Train  Project),  4.9.6  (Install  Im¬ 
provement),  and  4.9.7  (Evaluate  Deployment)  appear  to  be 
sequential,  they  are  usually  done  somewhat  in  parallel, 
and  may  take  some  iteration.  For  example,  a  tool  may  have 
to  be  installed  for  training  to  effectively  be  provided  for  it. 
Additionally,  it  may  not  be  possible  to  identify  certain 
needed  skills  until  their  absence  becomes  apparent.  Al¬ 
though  the  order  of  these  tasks  represents  an  ideal  situa¬ 
tion,  the  actual  implementation  must  be  determined  by  the 
existing  situation  and  environment. 

Objectives  •  Plan  the  training  for  the  project. 

Schedule  instructors  and  briefers. 

Set  up  support  relationships  for  the  project. 

Project  agrees  to  rollout  plan. 

Installation  plan  for  project  completed. 

Training  resources  are  available  to  project. 

Assess  project  skills  and  knowledge  in  area  of  change. 

Plan  curriculum  to  meet  skills  and  training  needs  of 
people  in  the  project. 

Schedule  courses  and  enroll  people  from  the  project. 
Conduct  courses. 


Entry  Criteria 


Tasks 
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4.9 

4.9.5 


The  Acting  Phase 
Rollout  Solution 
Train  Project 


Exit  Criteria 


•  Reassess  project  skills  and  knowledge;  retrain  as  neces¬ 
sary. 

•  Project  is  trained  in  specifics  of  this  process  change. 

•  Project  has  ongoing  support  for  installing  and  using 
changes. 

•  Training  plan  is  completed. 

•  Support  agreements  include  project 


CMU/SEI-96-HB-001 


121 


4.0  The  Acting  Phase 

4.9  Rollout  Solution 

4.9.6  Install  Improvement 


4.9.6  Install  Improvement 


Purpose 


Objectives 


Entry  Criteria 


Tasks 


Before  a  new  tool,  method,  or  process  can  be  used,  the  asso¬ 
ciated  supporting  environment  must  be  installed.  Various 
projects  in  the  line  organization  must  tailor  the  solution  to 
fit  their  environments  and  needs.  The  installation  is  when 
the  tailoring  is  performed;  the  tailoring  is  planned  for  in 
Step  4.9.4  on  page  119. 

For  lower  maturity  organizations  in  which  there  is  more 
variation  across  the  line  organization,  more  tailoring  to  ac¬ 
commodate  individual  needs  may  be  required.  As  the  orga¬ 
nization  moves  up  the  maturity  ladder,  less  local  tailoring 
will  be  required  for  organization-wide  improvements. 

Ensure  that  the  local  project  installs  and  can  successfully 
use  the  process  improvement. 

•  Installation  plan  for  project  is  approved. 

•  Project  included  in  support  contracts. 

•  Installation  plan  and  support  plans  for  the  project  are 
completed. 

•  Project  trained  in  specifics  of  process  improvement 

•  Tools,  artifacts,  and  documentation  to  support  imple¬ 
mentation  of  process  improvement. 

Specific  installation  tasks  vary  widely  depending  on  the 
nature  of  the  change.  New  tools  require  software  upgrades, 
installations,  file  system  changes,  etc.,  while  a  new  proce¬ 
dure  requires  an  update  to  hard-  and  soft-copy  documenta¬ 
tion.  The  tasks  listed  here  are  very  generic  and  shouldn’t 
limit  the  actual  installation. 

•  Plan  and  schedule  installation,  upgrades,  etc.  to  occur 
at  a  time  when  they  won’t  affect  critical  project  tasks. 

•  Carry  out  installation,  upgrade,  etc.,  verifying  correct 
new  operation  in  the  given  environment. 
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4.9  Rollout  Solution 

4.9.6  Install  Improvement 


•  Walk  through  new  operation  with  affected  people  in  the 
changed  environment.  Clean  up  any  problems  associat¬ 
ed  with  the  installation. 

•  Run  through  new  operation  at  normal  speed.  Clean  up 
any  problems  associated  with  the  installation. 

•  Review  installation  with  project  for  final  approval. 

•  Update/install  hard  and  soft  copy  documentation. 

Exit  Criteria  Project  has  sufficient  support  for  the  improvement. 
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4.9.7 


Evaluate  Deployment 


Purpose 


Objectives 


Entry  Criteria 


Tasks 


Exit  Criteria 


The  line  organization  conducts  an  evaluation  of  the  rollout 
to  gather  lessons  learned  regarding  deployment  of  the  new 
process  during  their  project,  giving  the  feedback  to  the 
SEPG  to  further  refine  the  installation  and  deployment 
processes.  By  providing  feedback  to  the  SEPG,  the  methods 
and  techniques  used  during  the  implementation  can  be  in¬ 
corporated  into  the  next  round  of  improvements. 

Gather  lessons  learned  from  deploying  improvements  and 
apply  to  future  deployments. 

•  Organization  has  fully  deployed  the  improvement  and 
has  been  using  it  for  a  few  cycles. 

•  Installation  plans  for  projects  are  completed. 

•  Process  metrics  reports  are  completed. 

•  Organization  rollout  strategy  and  plan  are  completed. 

•  Plan  and  schedule  lessons  learned  meeting(s). 

•  Survey  organization  to  collect  top-level  lessons,  issues, 
and  remaining  actions. 

•  Compile  lessons  learned  survey  results. 

•  Conduct  lessons  learned  meeting  to  clarify  findings. 

•  Package  lessons  learned  findings  and  review  with  orga¬ 
nization. 

•  Revise  generic  templates  for  rollout  strategy  and  plans 
and  installation  plans. 

•  Develop  action  plan  to  resolve  outstanding  issues  and 
finish  remaining  actions. 

•  Execute  action  plan  and  review  results  with  organiza¬ 
tion 

•  Lessons  learned  from  solution  rollout  captured. 
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4.9  Rollout  Solution 

4.9.7  Evaluate  Deployment 


•  SEPG  has  revised  generic  rollout  strategy  and  plans 
and  rollout  plan  templates. 

•  Lessons  learned  report  is  completed. 

•  Revised  generic  rollout  strategy  and  plans  and  rollout 
plan  templates  are  completed. 
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4.10 


Transition  to  Long-Term  Support 


Purpose 


Objectives 
Entry  Criteria 


Exit  Criteria 
Tasks 


The  process  improvement  should  not  require  constant  vig¬ 
ilance;  if  it  does,  it  should  to  be  retuned  (or  rethought).  The 
development  team  should  be  able  to  continue  without  a  lot 
of  guidance  and  support,  but  should  be  able  to  call  in  exper¬ 
tise  when  needed.  When  the  line  organization  demon¬ 
strates  that  it  can  repeatedly  execute  the  new  process, 
SEPG  involvement  falls  back  to  an  on-call  support  role,  and 
the  long-term  support  group  takes  over. 

Support  the  line  organization  in  normal  use  of  the  process. 

•  Changes  rolled  out  to  all  projects  in  the  organization. 

•  Long-term  support  agreements  and  funding  in  place. 

New  environment  makes  existing  contracts  obsolete. 

•  Line  organization  calls  on  long-term  support  provider 
instead  of  SEPG  when  problems  arise,  new  training  is 
needed,  specific  tailoring  is  required,  etc. 

•  SEPG  monitors  long-term  support  provider  to  ensure 
adequate  support  for  line  organization. 

•  MSG  periodically  reviews  long-term  support  to  ensure 
that  proper  funding  and  contractual  commitments  are 
being  met. 
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5.0  The  Leveraging  Phase 


Overview 


Purpose 


Now  that  the  organization  has  completed  one  cycle  through 
IDEAL  it  is  necessary  to  review  what  happened  during 
that  cycle  and  prepare  for  the  next  cycle  through  the  model. 

Rather  than  re-enter  IDEAL  at  the  Initiating  phase  on  sub¬ 
sequent  cycles  through  the  model,  by  performing  the  activ¬ 
ities  of  this  Leveraging  phase  you  will  reenter  IDEAL  at 
the  Diagnosing  phase.  The  Leveraging  phase,  in  addition  to 
preparing  for  the  next  cycle  through  IDEAL,  gives  you  the 
opportunity  to  “tune-up”  the  software  process  improvement 
(SPI)  process  before  starting  again. 

There  were  probably  some  false  starts,  omissions,  and 
some  activities  you  would  like  to  do  over  that  occurred  dur¬ 
ing  the  initial  cycle  through  IDEAL.  Since  you  have  kept 
track  of  the  lessons  learned  from  each  of  the  SPI  activities 
you  will  now  apply  them  during  the  Leveraging  phase  to 
make  the  SPI  process  work  better  during  the  next  cycle 
through  the  IDEAL  model. 

•  Review  and  analyze  lessons  learned  from  prior  phases. 

•  Incorporate  improvements  into  the  SPI  processes. 

•  Review  motivation  for  SPI. 

•  Review  and  evaluate  goals. 

•  Evaluate  sponsorship  and  commitment, 

•  Develop  plan  to  provide  continuing  guidance  to  the  SPI 
program. 
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Objectives 


Education/Skills 


•  Incorporate  lessons  learned  from  previous  phases  into 
SPI  approach. 

•  Gain  visibility  into  value  of  SPI. 

•  Reaffirm  continuing  SPI  sponsorship. 

•  Establish/adjust  high  level  goals  for  next  cycle. 

•  Determine  new  or  additional  baselines  that  may  be  nec¬ 
essary. 

•  Create  a  plan  to  guide  the  organization  through  the 
next  cycle. 

Training  and  skill  development  for  the  Leveraging  phase  is 
shown  in  the  following  table. 


Education/Skills 

MSG 

SEPG 

TWG 

Line 

Managers 

Practitioners 

Team  Development 

X 

X 

CMM  for  software 

X 

X 

X 

X 

SPI  skills 

X 

X 

X 

Planning  skills 

X 

X 

Commitment 


Communication 


The  commitment  expectations  for  the  Leveraging  phase 
are  similar  to  those  of  the  Initiating  phase.  Management 
must  provide  the  business  need  for  continuing  the  SPI  ac¬ 
tivities  and  must  be  willing  to  commit  the  necessary  re¬ 
sources  for  the  SPI  effort. 

As  with  commitment,  the  communications  aspect  of  the  Le¬ 
veraging  phase  is  very  similar  to  that  of  the  Initiating 
phase.  One  difference,  though,  is  that  there  should  now  be 
a  greater  amount  of  information  to  communicate  now  that 
you  have  completed  one  cycle  of  IDEAL. 
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5.0  The  Leveraging  Phase 


Entry  Criteria 


Exit  Criteria 


Some  of  the  things  that  you  should  communicate  to  the  or¬ 
ganization  are 

•  results  from  the  first  cycle  through  IDEAL 

•  enhanced  business  objectives  and  goals 

•  changes  that  may  have  occurred  to  the  infrastructure 

•  updated/revised  approach  to  SPI 

•  A  cycle  through  the  previous  phases  of  the  IDEAL  mod¬ 
el  has  been  completed. 

•  Lessons  learned  reports  from  each  of  the  previous  phas¬ 
es  are  available. 

•  Artifacts  produced  during  SPI  implementation  are 
available. 

•  Lessons  learned  are  analyzed  and  improvements  incor¬ 
porated  into  SPI  processes. 

•  Sponsorship  and  commitment  have  been  reaffirmed 
with  senior  management. 

•  High  level  goals  are  established  for  the  next  cycle. 

See  Figure  5-1  on  page  130  for  a  pictorial  representation  of 

the  tasks  associated  with  the  Leveraging  phase  of  the  IDE¬ 
AL  model. 
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5.0 


The  Leveraging  Phase 


Figure  5-1 :  Process  Flow  for  Leveraging  Phase 
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Tasks 


The  tasks  for  the  Leveraging  phase  are  shown  in  the  table 
below. 


Tasks 

Page 

Number 

'  5.1:  Gather  Lessons  Learned 

132 

5.2:  Analyze  Lessons  Learned 

133 

5.3:  Revise  Organizational  Approach 

135 

5.4:  Review  Sponsorship  and  Commitment 

136 

5.5:  Establish  High  Level  Goals 

137 

5.6:  Develop  New/Revised  Software  Process  Improvement  (SPI)  Proposal 

138  1 

1 

5.7:  Continue  With  SPI 

139 

I 
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5.1  Gather  Lessons  Learned 


5.1 

Gather  Lessons  Learned 

Purpose 

The  purpose  of  this  step  is  to  insure  that  all  of  the  lessons 
learned  data  is  available  for  review  prior  to  starting  the 
next  cycle  through  IDEAL.  A  reasonable  amount  of  time 
has  passed  since  you  last  went  through  the  prior  phases  of 

IDEAL,  possibly  as  long  as  18  to  24  months.  Without  the 
documented  lessons  learned  that  were  gathered  during 
each  phase  it  will  be  hard  to  remember  the  activities  that 
occurred  during  previous  phases. 

Hopefully,  you  have  been  gathering  lessons  learned 
throughout  the  SPI  activity  and  this  data  resides  in  the  or¬ 
ganizations  process  database.  If  it  doesn’t,  it  needs  to  be 
gathered  from  wherever  it  may  reside. 

Objectives 

•  Insure  that  all  lessons  learned  information  regarding 
the  activities  performed  during  the  previous  cycle  are 
available  for  review. 

•  Refresh  yoiu*  memory  regarding  the  activities  from  the 
previously  completed  phases  of  the  IDEAL  model. 

Entry  Criteria 

Acting  phase  has  been  completed  for  some  or  most  of  the 

TWGs. 

Exit  Criteria 

Lessons  learned  from  previous  phases  of  IDEAL  are  avail¬ 
able. 

Tasks 

•  Gather  lessons  learned  from  previous  SPI  activities. 

•  Interview  SPI  process  participants  to  get  their  perspec¬ 
tives  on  previous  SPI  activity. 

•  technical  working  group  (TWG)  leaders, 
members 

•  pilot  project  personnel 

•  management  infrastructure  members 
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5.2 


Analyze  Lessons  Learned 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


The  purpose  of  this  step  is  to  make  sure  that  the  process 
you  are  using  for  SPI  is  the  best  that  you  can  make  it. 

Now  that  you  have  gathered  all  of  the  information  and  ar¬ 
tifacts  from  the  previous  cycle  through  IDEAL  it  is  time  to 
reflect  on  the  processes  you  followed,  or  didn’t  follow.  The 
purpose  of  this  activity  is  to  learn  from  the  mistakes  or 
omissions  that  you  may  have  made  in  the  previous  cycle 
and  modify  and  change  your  approach  so  you  don’t  repeat 
them. 

You  are  looking  for  ways  to  make  things  better  for  all  on 
this  next  cycle  through  the  model. 

•  Analyze  past  practices  and  processes  for  improvements 
to  make  to  them  to  make  the  next  cycle  through  IDEAL 
work  better. 

•  Consider  deleting  and  replacing  processes  that  did  not 
work  well. 

•  Consider  adding  new  processes  that  will  make  SPI  work 
better. 

•  Completion  of  the  previous  phases  of  the  IDEAL  model 
accomplished. 

•  Lessons  learned,  artifacts  and  other  information  re¬ 
garding  the  previous  cycle  through  IDEAL  readily 
available. 

•  Data  from  the  interviews  of  SPI  participants  regarding 
the  previous  SPI  cycle  are  available. 

•  Review  and  analysis  of  the  activities  performed  in  the 
previous  IDEAL  cycle  completed. 

•  Adjustments  or  plans  for  adjustments  in  the  SPI  ap¬ 
proach  confirmed. 
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5.2  Analyze  Lessons  Learned 


Tasks 


Review  lessons  learned  reports. 

Review  artifacts  produced. 

Review  overall  approach  to  SPI. 

Review  communications  activity. 

Review  interview  results  from  SPI  participants  regard¬ 
ing  previous  SPI  cycle. 

Review  effectiveness  of  the  SPI  infrastructure  that  was 
in  place. 

Interview  all  levels  of  management  to  include  their  in¬ 
puts. 

Survey  other  organizations  and  the  literature  to  see 
what  others  are  doing  regarding  the  process  for  SPI. 
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5.3 


Revise  Organizational  Approach 


Purpose 


Objectives 


Exit  Criteria 


Entry  Criteria 


Tasks 


The  purpose  of  this  step  is  to  make  the  next  cycle  through 
the  SPI  process  more  effective  and  efficient.  Any  enhance¬ 
ments  you  can  make  to  the  SPI  process  will  allow  you  to 
make  improvement  changes  more  effectively,  reduce  resis¬ 
tance  to  change  and  allow  SPI  to  proceed  at  a  faster  pace. 

•  Develop  more  effective  and  efficient  SPI  process. 

•  Reduce  resistance  to  SPI. 

•  Insure  effective  sponsorship  for  SPI. 

•  SPI  approach  modified  for  entry  into  the  next  cycle 
through  the  IDEAL  model. 

•  The  documented  approach  to  SPI  has  been  revised  to  re¬ 
flect  the  corrections  and  additions  resulting  from  the  re¬ 
view  and  analysis  of  lessons  learned. 

•  Lessons  learned  have  been  reviewed  and  analyzed. 

•  Interviews  with  participants  have  been  conducted. 

•  Industry  trends  have  been  reviewed. 

•  Artifacts  (plans,  procedures,  etc.)  from  previous  SPI  cy¬ 
cle  are  available. 

•  Results  from  the  analysis  of  lessons  learned  and  the  re¬ 
sults  from  participant  interviews  regarding  the  previ¬ 
ous  SPI  cycle  are  available. 

•  Revise  the  previous  approach  to  SPI. 

•  Document  the  new  approach. 

•  Make  changes  to  infrastructure  if  necessary. 
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5.4  Review  Sponsorship  and  Commitment 


Purpose  As  you  have  probably  recognized  during  the  previous  cycle, 

sponsorship  and  commitment  are  critical  to  the  success  of 
SPI.  As  you  did  the  first  time  through  the  Initiating  phase, 
make  sure  you  have  sufficient  sponsorship  and  commit¬ 
ment  to  support  the  SPI  program. 

Objectives  .  Insure  that  management  is  committed  to  the  SPI  effort 

and  will  continue  to  provide  the  sponsorship  and  com¬ 
mitment  necessary  for  the  program  to  succeed. 

•  Insure  that  resources  will  be  available  to  continue  the 
SPI  program. 

Entry  Criteria  Revised  approach  to  SPI  agreed  upon  and  documented. 

Management  has  confirmed  continuing  sponsorship 
and  commitment  to  the  SPI  program. 

Management  has  agreed  to  provide  resources  and  over¬ 
sight  to  the  SPI  program. 

Review  commitment  and  sponsorship  levels  required 
with  senior  management. 

Review  revised  SPI  approach  with  senior  management. 
Review  resoxu-ces  required  with  senior  management. 


Exit  Criteria 


Tasks 
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5.5 


Establish  High  Level  Goals 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


Tasks 


As  in  the  Initiating  phase,  general,  high-level  goals  need  to 
be  established.  These  goals  will  be  made  more  specific  dur¬ 
ing  the  action  planning  activity  of  the  Establishing  phase. 

Clearly  defined,  measurable  goals  are  necessary  to  provide 
guidance  and  to  assist  in  developing  tactics  for  improve¬ 
ment.  They  also  allow  objective  measurement  of  the  im¬ 
provement  results. 

•  Refine  the  long  term  goals. 

•  Refine  the  measurements  and  the  measurement  pro¬ 
cess  to  objectively  determine  goal  satisfaction. 

•  Link  the  SPI  program  to  the  organization’s  vision  and 
business  needs. 

•  Sponsorship  and  commitment  have  been  reaffirmed. 

•  Updated  SPI  process  documented  and  agreed  upon. 

•  SPI  strategic  goals  from  last  cycle  is  available. 

•  Lessons  learned  regarding  goal  setting  from  past  im¬ 
provement  efforts  are  available. 

•  General  goals  for  SPI  reviewed  and  updated/defined. 

•  SPI  program  linked  to  the  organizations  vision  and 
business  needs. 

•  High  level  goals  for  next  cycle  through  IDEAL  have 
been  agreed  upon  and  documented. 

•  Review  goals  fi-om  previous  cycle  through  IDEAL  to  de¬ 
termine  if  they  are  still  applicable. 

•  Define  new  goals  as  appropriate  and  in  concert  with  the 
organization’s  vision,  business  needs  and  strategy. 

•  Review  lessons  learned  from  prior  cycle  goal  setting  ac¬ 
tivities. 
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5.6 


Develop  New/Revised  Software  Process 
Improvement  (SPI)  Proposal 


Purpose 


Objectives 


Entry  Criteria 


Exit  Criteria 


Tasks 


Until  the  strategic  action  plan  is  updated  or  recreated,  the 
SPI  program  needs  some  initial  guidance.  The  purpose  of 
this  step  is  to  create  a  plan  to  guide  the  program  up  to  the 
action  planning  steps. 

The  activities  will  he  very  similar  to  those  performed  in  the 
Initiating  phase  when  the  initial  proposal  for  SPI  was  cre¬ 
ated. 

Provide  guidance  to  the  SPI  program  until  any  necessary 
baselines  are  completed  and  a  new  action  plan  is  created. 

•  Sponsorship  and  commitment  reaffirmed. 

•  High  level  goals  established. 

•  Infrastructure  in  place  and  operating. 

A  plan  to  provide  guidance  for  the  SPI  program  is  docu¬ 
mented  and  approved. 

Develop  plan  to  provide  initial  guidance  for  SPI  program. 
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Purpose  The  purpose  of  this  activity  is  to  move  into  the  main  part  of 

the  SPI  program  and  start  the  continuous  cycle  of  the  pro¬ 
cess  improvement  program. 

Objectives  Transition  from  the  Leveraging  phase  into  the  Diagnosing 

phase. 


Entry  Criteria 


Exit  Criteria 
Tasks 


•  Revised/updated  approach  to  SPI  documented  and  ap¬ 
proved. 

•  SPI  goals  reviewed/updated. 

•  Sponsorship  and  commitment  has  been  reaffirmed. 

•  Infrastructure  in  place  and  operating. 

Agreement  and  approval  to  continue  SPI  program. 

Obtain  senior  management  approval  to  continue  the  SPI 
program. 
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6.0  Manage  the  Software  Process 

Improvement  Program 


Overview  Software  process  improvement  will  be  a  significant  under¬ 

taking  for  an  organization.  To  coordinate  the  many  activi¬ 
ties  that  will  occur  in  the  course  of  a  software  process  im¬ 
provement  (SPI)  program  requires  an  effective  infrastruc¬ 
ture  for  support.  Additionally,  the  infrastructure  must  be 
able  to  react  in  a  timely  manner  to  the  demands  of  the  SPI 
program. 

At  the  initiation  of  the  SPI  program,  an  initial  SPI  infra¬ 
structure  was  put  in  place  to  manage  the  activities  that  the 
organization  would  be  undertaking  during  its  SPI  pro¬ 
gram.  A  good  time  to  review  how  well  this  infrastructure 
has  performed  is  after  some  time  has  passed  and  the  initial 
accomplishments — bmlding  support,  obtaining  sponsor¬ 
ship,  gaining  commitment,  completing  the  baselining  activ¬ 
ities,  and  completing  action  planning — ^have  been  achieved. 

Some  questions  to  answer  about  the  performance  of  the  in- 
fi’astructure  that  was  initially  put  in  place  are 

•  Has  the  infrastructure  effectively  linked  the  SPI 
program  to  the  organization’s  mission  and  vision? 

•  Has  the  infrastructure  been  able  to  obtain  and  allocate 
sufficient  resources  to  ensure  timely  accomplishments? 

•  Has  the  infrastructure  monitored  the  SPI  program 
properly  and  provided  guidance  and  correction  as  neces¬ 
sary? 

As  the  organization  moves  from  the  initial  baselining 
phase  of  the  SPI  program  into  the  improvement  implemen¬ 
tation  phase,  it  is  critically  important  to  have  in  place  a 
strong,  responsive,  and  supportive  infrastructure. 
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The  improvement  activities  will  not  occur  in  a  vacuum  nor 
will  they  occur  in  a  serial  fashion.  Once  the  SPI  program  is 
under  way,  there  will  be  multiple  improvement  activities 
occurring  across  different  organizational  units.  For  exam¬ 
ple,  there  may  be  technical  working  groups  (TWGs)  ad¬ 
dressing  configuration  management,  requirements  man¬ 
agement,  project  planning,  and  peer  reviews  all  simulta¬ 
neously.  The  infrastructure  must  keep  track  of  all  this  and 
be  prepared  to  provide  the  required  oversight  and  guidance 
to  the  efforts. 

The  supporting  infrastructure  must  be  aware  that  TWGs 
can  and  probably  will  operate  in  parallel.  At  any  time,  the 
improvement  infrastructure  must  be  prepared  to 

•  Offer  support  for  a  technology  being  introduced. 

•  Coordinate  training  resources. 

•  Continue  to  build  and  provide  sponsorship. 

•  Provide  planning  expertise. 

•  Assess  organizational  impact. 

•  Show  lessons  learned. 

In  short  the  infrastructure  must  perform  many  manage¬ 
ment  functions  for  the  organization  as  it  progresses  with 
the  SPI  program. 

The  tasks  for  this  phase  are  shown  in  the  table  below. 


Task 

Page 

Number 

6.1 :  Setting  the  Stage  for  Software  Process  Improvement  (SPI) 

143 

6.2:  Organizing  the  SPI  Program 

146 

6.3:  Planning  the  SPI  Program 

153 

6.4:  Staffing  the  SPI  Program 

- - - - - - - 

156 

6.5:  Monitoring  the  SPI  Program 

159 

6,6:  Directing  the  SPI  Program 

164 

_ 1 
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6.1  Setting  the  Stage  for  Software  Process 

Improvement  (SPI) 


Purpose  Once  the  SPI  program  is  started,  management  has  the 

most  challenging  and,  in  some  sense,  the  most  rewarding 
responsibility.  Significant  challenges  will  come  from  the  or¬ 
ganization’s  resistance  to  change,  cost,  schedule  demands 
and  inevitable  slow  progress  that  seem  to  characterize  all 
improvement  efforts.  Management  must  keep  the  SPI  pro¬ 
gram  focused  on  improvements  connected  to  the  organiza¬ 
tion’s  vision  and  mission. 

To  keep  the  SPI  program  focused  over  the  long  term,  a 
management  infi*astructure  will  be  required.  'This  manage¬ 
ment  infrastructure  will  be  required  to  make  changes  of  fo¬ 
cus  and  adjustments  to  priorities  many  times  as  the  effort 
proceeds.  These  changes  will  be  driven  by  both  internal 
and  external  factors,  changes  in  the  marketplace,  shortage 
of  resources,  critical  skill  availabihty,  availability  of  new  or 
improved  technologies,  and  any  of  a  host  of  other  factors. 

One  of  the  biggest  challenges  that  the  management  infra¬ 
structure  will  have  to  deal  with  is  the  organization  itself. 
The  organization  has  a  culture,  and  the  SPI  program  in 
some  cases  will  be  asking  this  culture  to  change.  Guiding 
an  organization  through  a  change  in  culture  takes  time. 

A  sigmficant  challenge  related  to  dealing  with  the  organi¬ 
zation  is  management  itself  Management  must  be  able  to 
recognize  that  they  are  a  significant  part  of  the  organiza¬ 
tional  culture  and  that  they  may  also  be  required  to  change 
as  the  organization  changes. 

Managers  must  be  able  to  divorce  themselves  from  cultural 
biases  and  organizational  biases  and  be  aware  of  the  differ¬ 
ing  perspectives  fi'om  different  groups  that  make  up  the  or¬ 
ganization.  'They  must  work  to  integrate  these  different 
groups  into  the  SPI  program,  building  consensus  and  sup¬ 
port  for  the  SPI  program  as  they  proceed. 
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As  the  organization  progresses  through  the  SPI  program, 
problems  sometimes  arise  when  new  or  different  technolo¬ 
gies  are  introduced  to  effect  the  improvements. 

The  difficulty  in  introducing  a  new  technology  lies  not  in 
the  fact  that  the  technology  is  new  but  in  the  fact  that  the 
technology  will  require  change.  Change  is  the  culprit.  As 
new  or  different  technology  is  introduced  during  the  SPI 
program,  people  will  be  asked  to  do  their  jobs  differently, 
work  with  different  equipment,  work  with  different  tools, 
or  possibly  change  positions  within  the  organization.  Peo¬ 
ple  will  be  asked  to  move  out  of  their  comfort  zone  into 
something  that  is  unknown  to  them. 

It  is  a  very  common  occurrence  within  an  improvement  ef¬ 
fort  to  require  people  to  change  the  way  they  currently  do 
their  work,  and  it  is  also  a  very  common  and  natural  for 
people  to  resist  the  change.  Why  should  they  change  some¬ 
thing  that  they  have  grown  comfortable  with  for  something 
that  is  unknown  to  them?  The  management  infrastructure 
should  be  prepared  for  and  expect  resistance  to  the  im¬ 
provement  initiative.  Regardless  of  whether  the  improve¬ 
ments  are  viewed  as  a  good  thing  or  a  bad  thing,  there  will 
still  be  change  and  there  will  be  resistance. 

Being  able  to  recognize  that  this  resistance  to  change  is  oc¬ 
curring  and  being  able  to  deal  with  it  effectively  is  critical 
to  the  success  of  the  SPI  program. 

The  type  and  amount  of  resistance  will  vary  from  organiza¬ 
tion  to  organization,  depending  on  the  culture  that  exists 
within  the  organization. 

Resistance  will  occur  in  two  forms:  overt  and  covert.  It  is 
easier  for  management  to  deal  with  the  overt  resistance,  as 
it  is  out  in  the  open  and  easily  recognized.  The  harder  chal¬ 
lenge  will  be  to  surface  covert  resistance  so  that  it  is  more 
recognizable  and  easier  to  deal  with.  Being  aware  that  re¬ 
sistance  will  occur — that  it  is  not  always  on  the  surface — 
and  being  able  to  recognize  it  when  it  is  surfaced  will  make 
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Objectives 


Entry  Criteria 


Tasks 


things  go  a  lot  smoother.  However  managing  the  SPI  pro¬ 
gram  will  still  be  a  difficult  challenge. 

•  Establish  priorities  for  the  SPI  program. 

•  Approve  SPI  strategic  action  plans. 

•  Allocate  resources. 

•  Monitor  improvement  progress  against  plan. 

•  Develop  reward  system. 

•  Provide  continuing,  visible  sponsorship. 

•  Commitment  made  to  establish  and  implement  a  SPI 
program. 

•  Proposal  for  SPI  program  completed  and  approved. 

•  Resources  for  SPI  program  authorized. 

•  Business  needs  identified. 

•  Review  and  select  baselines  that  are  needed. 

•  Review  resource  requirements  for  the  SPI  program. 

•  Tailor  guide  activities  as  appropriate  for  the  organiza¬ 
tion. 

•  Develop  sponsorship  activities. 

•  Introduce  concepts  of  managing  technological  change 
and  technology  transition. 

•  Obtain  training  on  ability  to  recognize  and  deal  with  re¬ 
sistance  to  change  that  will  present  themselves  to  the 
improvement  program. 
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6.2  Organizing  the  SPI  Program 


Purpose  As  a  SPI  program  gets  under  way,  an  infrastructure  must 

be  developed  and  put  in  place.  This  infrastructure  will  have 
the  responsibility  of  providing  guidance  for  the  SPI  pro¬ 
gram. 

In  most  cases  there  will  be  three  components  to  the  organi¬ 
zation’s  SPI  infrastructure: 

1.  Software  engineering  process  group  (SEPG). 

2.  Management  steering  group  (MSG). 

3.  Technical  working  group  (TWG). 

These  are  generic  names  and  may  vary  from  organization 
to  organization.  The  components  of  the  infrastructure  and 
their  relationship  to  each  other  are  largely  determined  by 
such  factors  as  organization  size  and  geographical  diversi¬ 
ty.  Figure  6-1  below  is  an  illustration  of  the  components  of 
a  t3T5ical  SPI  infrastructure. 


Figure  6-1 :  Components  of  a  Typical  SPI  Infrastructure 
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First  and  most  important  is  the  SEPG,  sometimes  called 
the  process  group.  The  SEPG  performs  many  functions  for 
the  organization  in  its  SPI  programs.  The  SEPG 

•  helps  to  sustain  support  for  the  SPI  program  in  an 
environment  of  change 

•  builds  and  reinforces  sponsorship 

•  nurtures  and  sustains  the  individual  improvement 
activities 

•  ensures  coordination  of  these  activities  throughout  the 
organization 

The  SEPG  is  chartered  by  the  MSG.  This  charter  acts  as 
the  contract  between  management  and  the  SEPG.  The 
charter  t3rpically  outlines  the  role,  responsibility,  and  au¬ 
thority  of  the  SEPG. 

It  cannot  be  emphasized  too  strongly  that  the  SEPG  is  not 
the  implementor  of  the  improvements.  The  role  of  the 
SEPG  is  that  of  a  facilitator,  helping  to  guide  the  process 
improvement  activity.  The  SEPG  also  plays  a  support  role, 
helping  the  projects  with  any  difficxilties  that  they  may  en¬ 
counter  as  they  implement  process  improvement. 

In  most  cases,  members  of  the  SEPG  are  recruited  from  the 
organization’s  existing  staff  of  software  engineering  profes¬ 
sionals.  The  support  that  the  organization’s  management 
demonstrates  for  the  SPI  program  will  influence  the  ability 
to  recruit  quality  people  for  membership  in  the  SEPG. 

Membership  in  the  SEPG  is  on  both  a  full-time  and  a  part- 
time  basis.  Obviously,  it  is  most  desirable  to  have  all  mem¬ 
bers  of  the  SEPG  dedicated  100%,  but  this  is  not  always 
achievable  in  practice.  Part-time  members  can  be  used  for 
periods  of  time  when  the  SEPG  has  a  lot  of  activity  occur¬ 
ring  for  a  finite  period  of  time.  It  is  strongly  recommended 
that  the  organization  have  at  least  one  person  dedicated 
full  time  to  the  SEPG  and  that  he  or  she  be  the  SEPG  lead¬ 
er. 

Characteristics  of  a  t3q)ical  member  of  the  SEPG  include 
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•  experience  as  a  practitioner 

•  expert  knowledge  in  one  or  more  domains 

•  good  interpersonal  skills 

•  respect  of  their  peers  in  the  organization 

It  will  be  a  difficult  task  to  draw  these  people,  who  are  some 
of  the  best  and  the  brightest  that  the  organization  has, 
away  from  a  project  manager  who  has  responsibility  for  a 
critical  project. 

Some  staff  will  want  to  become  members  of  the  SEPG.  The 
ease  with  which  staff  can  be  recruited  will  depend  on  the 
perceived  level  of  management  support  for  the  SPI  pro¬ 
gram.  Projects  may  lose  some  of  their  best  people  to  the 
SEPG.  This  must  be  allowed  to  happen.  The  organization 
should  not  sacrifice  long-term  gain  for  the  organization  as 
a  whole  in  favor  of  short-term  gain  for  an  individual 
project. 

In  the  long  run,  the  organization  must  do  all  it  can  to  en¬ 
sure  the  success  of  the  SPI  program;  yet  this  has  to  be  bal¬ 
anced  against  the  needs  of  the  individual  projects.  The 
SEPG  candidates  must  support  the  SPI  program,  be  will- 
ing  to  act  as  champions  for  the  SPI  program,  and  be  willing 
to  serve  as  agonts  of  change  to  the  rest  of  the  organization. 

The  leader  of  the  SEPG  must  be  a  respected  member  of  the 
organization  with  proven  ability.  The  SEPG  leader  should 
also  have  the  confidence  of  his  or  her  peers  and  be  looked 
on  as  someone  who  can  get  things  done.  The  SEPG  leader 
also  must  have  the  support  and  confidence  of  senior  man¬ 
agement. 

In  some  instances,  organizations  have  written  formal  job 
descriptions  describing  the  duties  and  responsibilities  of  an 
SEPG  member.  They  then  have  posted  the  open  positions 
for  all  to  see  and  review,  screened  applications,  and  con¬ 
ducted  a  rigorous  interview  process  in  selection  of  the  per¬ 
sonnel  to  staff  the  SEPG.  By  doing  the  staffing  in  this  man¬ 
ner,  management  sends  a  clear  message  to  the  organiza¬ 
tion  about  their  view  of  the  importance  of  the  SPI  program. 
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The  SEPG  will  report  on  their  activities  to  the  second  com¬ 
ponent  of  the  infrastructure,  the  MSG.  Additional  names 
for  the  MSG  include  quality  management  board,  process 
improvement  steering  committee,  and  management  steering 
team,  etc.  The  MSG  is  responsible  for  linking  the  SPI  pro¬ 
gram  to  the  organization’s  vision  and  mission. 

Some  of  the  duties  of  the  MSG  include 

•  demonstrating  sponsorship  for  the  SPI  program 

•  allocating  resources  for  the  improvement  activities 

•  monitoring  the  progress  of  the  SPI  program 

•  providing  guidance  and  correction  to  the  improvement 
activities  as  necessary 

Membership  of  the  MSG  is  usually  includes  senior  manag¬ 
er  as  leader  and  selected  members  of  his  or  her  manage¬ 
ment  team  making  up  the  rest  of  the  group.  This  team 
makes  up  a  standing  committee,  meeting  regularly  to  ad¬ 
dress  matters  relative  to  the  SPI  program.  The  MSG  usu¬ 
ally  meets  monthly,  but  in  the  early  stages  of  a  SPI  pro¬ 
gram  it  may  meet  more  frequently  to  insure  a  proper  start. 

The  third  main  component  of  the  SPI  infrastructure  is  the 
TWGs.  Additional  names  for  these  groups  include  process 
action  teams  and  process  improvement  teams.,  etc. 

These  working  groups  are  created  to  address  a  particular 
focus  of  the  SPI  program.  For  example,  there  could  be  a 
configuration  management  TWG  or  a  project  planning 
TWG  addressing  a  specific  software  engineering  domain. 
Also  the  TWGs  do  not  necessarily  have  to  address  technical . 
domains  for  improvement — they  could  address  such  things 
as  travel  reimbursement,  software  standardization,  or  pur¬ 
chasing,  for  example. 

The  TWG  is  typically  made  up  of  those  practitioners  in  the 
organization  who  have  knowledge  and  experience  of  the 
area  xmder  evaluation.  Membership  will  also  include  those 
who  would  be  affected  by  any  improvement  changes  that 
would  be  implemented  as  a  result  of  the  investigation. 
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The  TWGs  typically  have  a  finite  life,  the  duration  of  which 
is  usually  defined  in  the  charter.  After  the  completion  of 
the  TWG  objective,  it  is  disbanded,  and  the  members  re¬ 
turn  to  their  normal  duties. 

During  the  early  phases  of  the  SPI  program,  issues  of  scope 
usually  cause  TWGs  to  underestimate  the  time  required  to 
complete  their  objectives.  This  results  in  TWGs  going  back 
to  the  MSG  requesting  more  time  or  a  reduced  scope. 
Knowledge  gained  from  TWG  experience  will  reduce  these 
occurrences  as  the  scope  of  the  working  groups  comes  to  be 
more  specifically  defined. 

The  TWGs  report  to  the  MSG.  At  the  monthly  meeting  that 
the  MSG  holds,  the  agenda  will  always  include  a  status 
briefing  from  each  of  the  active  TWGs.  The  TWGs  also  have 
a  dotted  line  reporting  relationship  to  the  SEPG.  This  al¬ 
lows  the  SEPG  to  fulfill  its  charter  of  being  the  focal  point 
for  process  improvement  for  the  organization  by  keeping 
abreast  of  the  improvement  activities  that  are  under  way 
in  the  organization.  This  also  allows  the  SEPG  to  create  a 
repository  of  artifacts  that  have  been  produced  and/or  used 
during  the  improvement  process.  This  repository,  also 
called  the  process  database,  contains  records  of  the  data 
gathered  and  generated  during  the  improvement  process. 
This  process  database  provides  a  ready  reference  for  mea¬ 
suring  results  of  the  SPI  program.  It  also  provides  a  mech¬ 
anism  for  familiarizing  new  personnel  with  the  operation 
as  they  join  the  SPI  program.  Physically  the  process  data¬ 
base  will  probably  be  a  combination  of  artifacts  in  file 
drawers,  multiple  forms  of  data  held  in  some  machine  read¬ 
able  form  that  belongs  to  the  SEPG,  and/or  such  things  as 
electronic  mail  messages. 


150 


CMU/SEI-96-HB-001 


6.0  Manage  the  Software  Process  Improvement  Program 
6.2  Organizing  the  SPI  Program 


Objectives 

Entry  Criteria 

Additionai 

Components 


•  Establish  infrastructure  to  guide  and  manage  the  SPI 
program. 

•  Create  organizational  awareness  of  the  SPI  program. 
Commitment  to  establish  and  implement  a  SPI  program. 

In  some  instances,  benefit  can  be  gained  from  having  addi¬ 
tional  components  to  the  SPI  infrastructure.  Typically, 
these  additional  components  are  formed  in  organizational 
environments  that  are  either  very  large  and/or  have  wide 
geographical  disbursement. 

The  first  of  these  additional  components  is  an  executive 
council  (EC).  Members  of  the  EC  are  made  up  of  the  senior 
management  from  each  division.  The  EC  provides  broad 
guidance  and  interpretation  of  the  organization’s  vision 
and  mission  and  communicates  this  interpretation  to  the 
divisions. 

At  the  division  level,  it  is  the  responsibility  of  the  MSG  for 
the  division  to  ensure  that  the  improvement  activities  in 
each  division  are  responsive  to  the  organization’s  vision 
and  mission  as  provided  by  the  EC. 

The  second  additional  component  is  usually  called  some¬ 
thing  similar  to  software  process  improvement  advisory 
committee  (SPIAC).  This  committee  is  usually  created 
when  an  organization  has  multiple  SEPGs  resulting  in 
multiple  improvement  efforts  occurring  across  different  lo¬ 
cations  within  the  organization.  Multiple  SEPGs  are  typi¬ 
cally  appropriate  when  an  organization  is  large  and  /  or 
geographically  dispersed. 

'The  SPIAC  serves  as  a  forum  where  each  of  the  multiple 
SEPGs  are  represented.  Through  this  forum,  sharing  of  ex¬ 
periences,  lessons  learned,  and  improvements  accom¬ 
plished  will  benefit  the  overall  program.  A  forum  in  which 
SEPGs  can  exchange  information  reduces  the  number  of 
false  starts,  so  that  SEPGs  do  not  have  to  duplicate  work 
that  other  SEPGs  have  already  done. 
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Figure  6-2  below  illustrates  how  an  improvement  infra¬ 
structure  might  look  in  a  very  large  organization. 


_ 

-  -  -^SPIAC^ 


SEPG^  SEPG^  (^SEPG^  (^SEPG  ^ 


Tasks 


Figure  6-2:  Typical  SPI  Infrastructure  in  a  Large  Organization 

.  Establish  the  MSG. 

•  Establish  the  SEPG. 

•  Develop  charter  for  the  SEPG  (MSG). 

•  Demonstrate  sponsorship  for  the  improvement  activi¬ 
ties. 

•  Develop  charter  template  for  the  TWGs. 
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Purpose  There  will  be  many  plans  that  will  be  developed  to  guide 

and  support  the  SPI  program.  Strategic  plans  are  the  re¬ 
sponsibility  of  management;  tactical  plans  to  address  spe¬ 
cific  improvement  activities  are  the  responsibility  of  the 
TWGs.  There  are  also  installation  plans  for  pilot  adoption 
activity,  and  plans  for  rollout  and  installation  of  improved 
processes  on  a  broad  scale.  Communication  plans  also  need 
to  be  developed  to  insure  that  communication  of  the  events 
associated  with  the  SPI  program  are  received  properly  by 
the  organization.  Each  of  these  plans  will  have  schedules 
that  must  be  monitored  and  defined  milestones  that  must 
be  reviewed.  These  schedules  and  milestones  will  be  used 
to  evaluate  progress  toward  a  specific  objective  allowing 
management  to  provide  the  necessary  oversight  to  the  ef¬ 
fort. 

Developing  the  SPI  strategic  action  plans  for  the  improve¬ 
ment  activities  starts  with  a  review  of  the  findings  and  rec¬ 
ommendations  that  resulted  from  the  baselining  activities. 
This  input  provides  the  starting  point  for  development  of 
the  SPI  strategic  action  plan.  These  findings  and  recom¬ 
mendations,  along  with  the  organization’s  vision,  mission, 
and  business  needs  will  help  determine  the  content,  prior¬ 
ity,  and  sequence  of  activities  for  the  SPI  program. 

One  of  the  continuing  activities  of  an  improvement  pro¬ 
gram  is  build  and  maintain  sponsorship  and  support  for 
the  initiative.  To  help  accomplish  this  objective,  it  would  be 
beneficial  to  the  program  to  find  and  fix  a  few  quick-fix, 
quick-return  improvement  projects — picking  the  so-called 
“low-hanging  frmt.”  Implementing  these  quick-fix  im¬ 
provements  and  communicating  their  occurrence  will  have 
many  benefits.  It  will  help  demonstrate  to  personnel  within 
the  organization  the  value  of  the  initiative  by  showing 
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Objectives 


some  immediate  benefit.  It  will  also  help  create  enthusi¬ 
asm  and  support  for  the  initiative. 

The  SEPG  works  at  both  the  tactical  level  and  the  strategic 
level  within  the  SPI  program,  but  it  will  probably  concen¬ 
trate  most  of  its  efforts  at  the  tactical  level,  addressing  is¬ 
sues  that  arise  as  the  SPI  program  proceeds. 

There  will  be  many  plans  developed,  modified,  discarded, 
and  completed  as  the  SPI  program  proceeds,  as  business 
conditions  change,  and  as  personnel  and  organizational 
changes  occur.  The  SPI  action  plan,  developed  as  a  result  of 
the  baselining  activities,  will  be  the  overall  guide  to  the  SPI 
program.  Subordinate  plans  will  include 

•  plans  to  guide  the  organization  to  the  point  where  the 
SPI  action  plan  is  developed  (Establishing  phase) 

plans  for  how  the  infrastructure  will  work 

•  plans  and  charters  for  the  TWGs  that  will  investigate 
and  provide  solutions  within  a  specific  problem  area 

•  plans  for  pilot  introduction  of  new  or  changed  technolo¬ 
gies 

•  plans  for  wide-scale  introduction  and  initiation  of  pilot¬ 
ed  changes 

•  plans  on  how  to  adopt  and  institutionalize  proven  im¬ 
provement  accomplishments 

Appendix  B.O  on  page  185  has  an  assortment  of  sample 
plans,  templates,  and  charters  along  with  some  discussion 
of  their  use  and  application. 

•  Define  goals  of  the  SPI  program. 

•  Provide  focus  and  direction  for  the  SPI  activities. 

•  Determine  resources  required  for  the  SPI  program. 

•  Show  commitment  for  the  SPI  program. 
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Entry  Criteria 


Tasks 


•  MSG  established. 

•  SEPG  established. 

•  Organizational  strategic  business  plan  exists. 

•  Review  existing  baselines  and  determine  if  new  base¬ 
lines  need  to  be  developed. 

•  Plan  for  and  schedule  training  required  for  the  selected 
baselines  and  strategic  planning  activities. 

•  Develop  organizational  plan  for  the  SPI  program. 

•  Based  on  results  from  the  baselining  activities,  develop 
SPI  action  plan. 

•  Based  on  prioritized  results  from  the  baselining  activi¬ 
ties,  develop  tactical  plans. 

•  Develop  detailed  schedules  through  completion  of  base¬ 
lining  and  strategic  planning. 

•  Review  and  approve  plans  developed  (MSG). 
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Staffing  the  SPI  Program 


Purpose  In  most  organizations,  existing  personnel  will  staff  the  SPI 

program.  These  resources  will  include  those  that  are  allo¬ 
cated  to  the  improvement  work  itself  and  those  that  are  as¬ 
signed  to  the  SPI  infrastructure  to  guide  and  manage  the 
SPI  program. 

In  addition  to  the  resources  devoted  to  the  management 
structure,  additional  resources  allocated  to  the  SPI  pro¬ 
gram  take  two  forms. 

The  first  are  personnel  resovu-ces  that  are  allocated  full 
time  and  make  up  the  SEPG.  Staff  to  fill  the  positions  in 
the  SEPG  will  usually  come  from  within  the  organization’s 
development  ranks.  The  success  of  the  SEPG  and  the  effec¬ 
tiveness  of  the  SPI  program  depend  largely  on  the  quality 
of  the  people  that  are  recruited  for  the  SEPG. 

The  SEPG  is  a  small  organization;  typically,  it  has  a  staff 
size  that  is  equal  to  1%  to  3%  of  the  organization’s  practi¬ 
tioners.  Occasionally,  extra  resoimces  will  be  needed  for 
some  specific  tasks.  To  provide  these  additional  resources 
for  the  SEPG  when  required,  there  may  be  some  temporary 
members  assigned  to  the  SEPG.  These  assignments  are 
usually  for  a  finite  period  of  time,  allowing  the  members 
enough  time  to  complete  their  specific  task  before  return¬ 
ing  to  their  previous  duties. 

A  second  set  of  resources  will  be  required  to  staff  the  TWGs 
that  will  be  formed  to  address  specific  improvement  issues. 
Resources  for  the  TWGs  are  usually  committed  as  a  per¬ 
cent  of  a  full-time  person;  for  example,  “John,  we  would  like 
you  to  spend  20%  of  your  time  for  the  next  8  months  work¬ 
ing  on  the  TWG  that  is  solving  our  requirements  manage¬ 
ment  problem.”  These  resources  are  committed  for  a  finite 
length  of  time,  usually  defined  in  the  TWG  charter,  and  are 
assigned  very  specific  responsibilities  within  the  SPI  pro¬ 
gram  by  the  MSG. 
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Objectives 


Entry  Criteria 


Tasks 


A  TWG  will  be  formed  by  the  MSG,  given  its  specific  char¬ 
ter  and  goals.  When  its  tasks  are  completed,  the  TWG  will 
be  disbanded.  There  are  some  instances  in  which  a  TWG  is 
active  continuously,  usually  addressing  broader  issues  and 
consuming  a  smaller  percentage  of  a  members’  time. 

T3rpically  TWG  membership  will  rotate  among  the  organi¬ 
zation’s  development  staff.  This  will  allow  the  organization 
to  provide  fresh  insight  into  the  problem-solving  process 
and  also  allow  more  personnel  to  become  further  exposed  to 
and  become  a  part  of  the  SPI  program. 

The  last  component  of  the  SPI  infi'astructure  that  will  need 
resources  assigned  to  it  is  the  MSG. 

For  the  most  part,  resources  assigned  to  the  MSG  come 
from  the  organization’s  existing  management  structiire,  al¬ 
though  it  is  not  unheard  of  to  have  input  from  the  customer 
community. 

In  most  cases  each  major  component  of  the  organization  is 
represented  on  the  MSG  by  at  least  one  member,  and  lead¬ 
ership  of  the  MSG  is  provided  by  the  senior  executive.  Ad¬ 
ditionally,  the  SEPG  is  typically  represented  on  the  MSG 
by  the  SEPG  leader,  usually  in  a  non-voting  capacity. 

•  Assign  management-level  staff  to  the  MSG. 

•  Recruit  qualified  staff  for  SEPG  membership. 

•  Recruit  and/or  assign  proper  representation  to  TWGs. 

•  MSG  established. 

•  SEPG  established. 

•  Assign  management  staff  to  the  MSG. 

•  Create  job  descriptions  for  the  SEPG  members. 

•  Recruit  staff  for  the  SEPG. 

•  Develop  guidelines  for  TWG  membership. 
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•  Recruit  and/or  assign  staff  to  the  TWGs. 

•  Review  resource  requirements  for  each  baselining  activ¬ 
ity  against  resources  available. 
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6.5  Monitoring  the  SPi  Program 


Purpose  As  the  SPI  program  proceeds,  one  of  the  responsibilities  of 

the  MSG  will  be  to  periodically  review  progress  of  the  ini¬ 
tiative  against  the  milestones  and  goals  that  are  defined 
and  documented  in  the  SPI  strategic  action  plan.  These 
progress  reviews  of  the  SPI  program  will  be  regularly 
scheduled,  and  occur  at  the  monthly  meeting  of  the  MSG. 

The  format  that  the  reviews  will  take  should  be  defined  in 
advance  by  the  MSG,  documented  in  the  TWG  charter  and 
should  have  the  same  format  from  review  to  review.  It  may 
take  a  few  cycles  of  review  meetings  to  determine  the  most 
productive  format  for  the  review  and  any  associated  arti¬ 
facts  that  are  used  or  distributed  at  the  review. 

Evaluation  activities  encompass  all  facets  of  an  organiza¬ 
tion’s  SPI  program.  Evaluators  ask  such  questions  as 

•  Are  we  doing  it  right? 

•  Are  we  doing  the  right  thing? 

•  Have  we  achieved  the  expected  benefits? 

•  Are  the  improvement  projects  on  schedule? 

To  monitor  the  SPI  program,  a  measurement  system  to 
evaluate  progress  must  be  in  place.  The  key  to  evaluating 
the  SPI  program  will  be  the  metrics  that  are  selected  for 
measurement  and  the  ease  with  which  they  can  be  gath¬ 
ered.  Measurement  will  occur  at  many  levels  throughout 
the  organization — ^from  very  low-level  measurements  such 
as  coding  errors  that  are  found  during  inspections  or  test¬ 
ing  to  higher  level  measures  such  as  the  rate  and/or  volume 
of  field  trouble  calls.  All  these  measures  should  be  main¬ 
tained  so  that  a  history  of  the  benefits  of  the  SPI  program 
will  be  available  when  needed. 

There  are  generally  two  forms  of  evaluation  of  the  SPI  pro¬ 
gram. 
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Objectives 


Entry  Criteria 


Micro-Evaluation 


1.  Micro-level  evaluation,  whose  parameters  are  defined 
during  the  baselining  and  planning  activities.  This  mi¬ 
cro-level  evaluation  deals  with  such  things  as  project 
schedules,  milestones,  process  performance,  process 
quality,  and  other  quantitative  measures. 

2.  Macro-level  evaluation,  which  deals  with  a  set  of  broad¬ 
er,  more  qualitative  issues  such  as  business  issues, 
business  value,  competitive  factors,  market  conditions, 
etc. 

Ensure  that 

•  improvement  activity  is  consistent  with  corporate 
objectives 

•  plans  for  the  SPI  program  are  being  followed 

•  progress  toward  improvement  goals  is  being  made 

•  TWGs  are  defined  and  operational. 

•  Working  group  plans  have  been  developed  and  ap¬ 
proved. 

The  infrastructure  evaluates  the  SPI  program  at  the  micro 
level  by  measuring  progress  of  the  SPI  program  quantita¬ 
tively.  This  evaluation  includes  the  existing  process  and 
technologies  and  also  the  setting  of  expectations  from  new 
or  different  processes  and  technologies  not  yet  in  use  by  the 
organization  but  being  considered  for  adoption. 

Process  performance  also  should  be  evaluated.  The  effec¬ 
tiveness  of  old  and/or  existing  processes  should  have  some 
type  of  metric  that  can  easily  be  applied  to  determine 
whether  or  not  these  processes  are  contributing  to  the  over¬ 
all  mission  of  the  organization.  Processes  should  also  be 
measured  to  enable  comparison  of  current  performance  to 
new  performance  when  new  or  improved  processes  are  im¬ 
plemented.  Once  new  processes  are  implemented,  they 
should  be  continuously  monitored  and  their  performance 
evaluated  to  ensure  that  the  benefits  expected  from  their 
introduction  are  being  achieved. 
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Quality  performance  of  the  processes  is  also  evaluated  at 
the  micro  level.  During  the  baselining  process  and  during 
the  development  of  plans  for  new  or  revised  processes, 
quality  expectations  and  quality  metrics  are  defined  and 
implemented  within  the  processes  to  verify  their  benefits. 
Later,  as  the  improvements  are  implemented,  a  longer 
range  comparison  of  expected  or  planned  results  can  be 
made. 

The  monitoring,  evaluating,  and  reporting  on  process  qual¬ 
ity  and  effectiveness  is  typically  the  responsibility  of  the 
software  quality  assurance  group.  The  SEPG  will  play  a 
supporting  role  in  this  effort.  The  SEPG  will  not  be  the  only 
group  assisting  in  this  effort.  Project  staff  will  also  provide 
input  regarding  quality  and  effectiveness  of  processes  used 
in  the  development  activity. 

Working  groups  will  provide  input  about  expectations  for 
new  processes  being  introduced  and  the  quality  and  effec¬ 
tiveness  of  existing  processes  that  they  are  investigating. 

At  the  micro  level  of  evaluation,  members  of  the  SEPG, 
quality  assurance  personnel,  the  TWGs,  and  the  project 
staff  are  responsible  for  evaluating  the  performance  of  the 
process  and  recommending  and  applying  control  mecha¬ 
nisms  to  achieve  the  expected  results. 

Macro-Evaluation  Evaluations  of  the  SPI  program  at  the  macro  level  tend  to 

be  more  qualitative  and  are  therefore  the  responsibility  of 
the  MSG. 

When  designing  the  new  processes,  consideration  must  be 
given  to  the  data  that  management  needs  to  make  these 
more  qualitative  evaluations  at  the  macro  level.  Manage¬ 
ment  will  also  consider  data  that  is  input  fi-om  other  soirnc- 
es  such  as  market  information,  competitive  information,  vi¬ 
sion  and  mission  interpretations,  and  input  from  the  gen¬ 
eral  business  environment. 

Monitoring  the  SPI  program  and  appl3dng  proper  control 
procedures  will  ensure  that  the  goals  and  objectives  of  the 
program  are  being  met.  It  will  also  ensure  that  the  program 
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is  consistent  with  corporate  strategies.  Each  component  of 
the  infrastructure  must  periodically  review  its  own 
progress  and  also  review  the  progress  of  its  subordinate  or¬ 
ganizations. 

Individual  improvement  efforts  are  evaluated  in  the  review 
meetings  that  have  been  defined  and  documented  in  the 
schedules. 

Periodically  reviewing  the  progress  of  the  improvement 
program  enables  detection  of  early  warning  signals  that 
can  indicate  that  the  SPI  program  is  off  track.  Two  key 
questions  should  be  asked  at  each  of  the  program  reviews: 

1.  Are  we  meeting  the  milestones  set  for  this  individual 
program? 

2.  Are  the  programs  consistent  with  the  strategic  direction 
of  the  corporation? 

The  format  that  the  reviews  will  take  should  be  defined  in 
advance  by  the  MSG  and  should  be  the  same  from  review 
to  review. 

The  plans  that  are  developed  to  guide  the  improvement  ac¬ 
tivities  will  include  identification  of  milestones,  scheduled 
review  meetings,  and  defined  deliverables.  The  regularly 
scheduled  in-process  reviews  will  compare  progress 
against  the  previously  agreed-upon  schedules.  In  this  man¬ 
ner,  the  MSG  will  be  able  to  get  early  warning  of  any  diffi¬ 
culty  occurring  within  the  SPI  program  and  be  able  to  pro¬ 
vide  corrective  action. 

After  evaluating  available  alternatives  and  selecting  a  so¬ 
lution  to  provide  for  improvement,  an  approach  for  intro¬ 
ducing  the  selected  solution  must  be  formalized.  This  in¬ 
cludes  obtaining  sponsorship,  planning  the  implementa¬ 
tion,  evaluating  risk,  and  selling  the  new  technology  to 
pilot  users.  After  selecting  the  pilot  and  testing  the  technol¬ 
ogy  and  approach  to  implementation  with  the  pilot,  the  re¬ 
sults  are  evaluated.  This  evaluation  answers  these  ques¬ 
tions: 
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•  Did  the  new  technology  improve  the  process  it  was 
selected  to  improve? 

•  Are  there  any  downstream  effects  that  were  not 
planned  for? 

•  What  lessons  were  learned  in  the  pilot  that  can  be  ap¬ 
plied  so  that  implementation  has  minimal  impact? 

From  the  lessons  learned  with  the  pilot,  the  implementa¬ 
tion  approach  is  revised  for  wide-scale  adoption.  The  re¬ 
vised  plan  from  the  pilot  is  used  to  introduce  the  technology 
on  a  broader  scale  across  the  organization. 

During  the  time  that  the  implementation  has  been  occur¬ 
ring  across  the  organization,  a  support  mechanism  for  the 
new  technology  must  be  established.  Also  at  this  time,  les¬ 
sons  learned  during  the  adoption  and  institutionalization 
process  should  be  documented  and  analyzed.  These  are  re¬ 
tained  in  the  process  database  for  use  in  future  adoption 
and  institutionalization  activities. 

From  time  to  time,  course  correction  or  change  of  focus  of 
the  SPI  program  may  be  necessary,  for  such  reasons  as 
business  opportunity,  organizational  or  personnel  changes, 
funding  issues,  and  others.  This  is  not  unusual  and  should 
not  be  cause  for  dismay.  By  having  scheduled,  periodic  re¬ 
views  of  the  activities  of  the  SPI  program,  the  MSG  will  be 
able  to  provide  the  necessary  guidance  and  be  able  to  make 
informed  decisions  regarding  the  overall  effort  at  the  earli¬ 
est  opportunity. 

•  Define  procedures  for  SPI  status/progress  reviews. 

•  Develop  schedule  for  SPI  status/progress  reporting 
meetings. 

•  Review  progress  against  SPI  strategic  action  plan. 

•  Review  process  performance  against  plan. 

•  Review  strategic  direction. 
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6.6  Directing  the  SPI  Program 


Purpose  The  SPI  program  needs  direction  on  two  levels — strategic 

and  tactical.  The  strategic-level  direction  insures  that  the 
overall  goals  of  the  organization  will  be  met.  The  tactical- 
level  direction  insures  that  specific  improvement  activity, 
consistent  with  the  strategic  goals,  is  accomplished.  The 
MSG  is  charged  with  providing  this  direction  to  the  effort. 

At  the  strategic  level,  the  MSG  will  ensure  that  the  SPI  ef¬ 
forts  are  linked  to  the  organization’s  overall  vision  and  mis¬ 
sion.  Working  at  this  strategic  level,  the  MSG  is  concerned 
with  a  broad  set  of  issues  that  can  affect  the  SPI  program 
Some  additional  areas  for  review  and  evaluation  include 
market  opportunities,  organizational  structure,  technology 
advances,  available  resources,  etc. 

Some  of  the  responsibilities  include 

•  reviewing  and  linking  together  the  existing  policies  of 
the  organization 

•  evaluating  how  these  existing  policies  help  or  hinder 
the  SPI  program  and  how  they  integrate  with  the  over¬ 
all  vision  and  mission 

The  MSG  will  tie  all  this  together.  Integrating  all  of  this 
with  the  findings  and  recommendations  from  the  baselin¬ 
ing  efforts  is  a  critical  step  in  determining  the  priorities  of 
the  SPI  program. 

Direction  at  the  tactical  level  is  focused  on  getting  the  prov¬ 
en  improvement  activities  completed  and  institutionalized. 
The  MSG  must  resolve  any  and  all  impediments  discovered 
during  the  evaluation  of  existing  organization  policy  and 
procedures. 

TWGs  must  be  chartered  to  address  specific  improvement 
areas  that  have  been  previously  agreed  upon  and  priori¬ 
tized  by  the  MSG.  The  charters  that  will  be  developed  must 
be  drafted  so  that  the  schedule,  milestones,  and  resources 
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are  understood  by  all  members  of  the  TWG.  Additionally 
the  progress  reporting  requirements  should  be  defined  and 
scheduled  for  the  duration  of  the  TWG. 

Directing  the  activities  of  the  SPI  program  will  not  be  as 
easy  as  it  appears.  Consideration  must  be  given  to  the  way 
in  which  changes  in  one  area,  no  matter  how  minor,  can 
have  a  ripple  effect  on  the  entire  organization. 

Such  events  can  be  prevented  by  making  sure  that  the 
proper  people  are  represented  on  the  TWGs  and  that 
changes  are  piloted  in  a  controlled  setting  before  being  re¬ 
leased  across  the  organization.  The  working  group  should 
include  users  of  the  process,  suppliers  to  the  process,  and 
receivers  of  the  finished  product.  By  itself  this  will  not  en¬ 
sure  that  the  problem  will  be  solved,  but  it  will  significantly 
reduce  its  chance  of  occurring. 

Ensure  that  SPI  program  direction  is  consistent  with  the 
organization’s  vision  and  mission. 

•  Organization’s  vision  and  mission  are  defined  and  doc¬ 
umented. 

•  Organization  policy  that  provides  gxiidance  to  the  soft¬ 
ware  development  activities  exists. 

•  Strategic  plan  is  available  that  prioritizes  the  improve¬ 
ment  activities. 

•  Review  existing  pohcies  and  procedures. 

•  Evaluate  existing  policies  and  procedures  to  determine 
priorities  for  establishing  TWGs. 

•  Authorize  and  initiate  TWGs  as  required. 

•  Evaluate  criteria  and  make  informed  decisions  regard¬ 
ing  priority  and  direction  of  SPI  program. 
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A.O  Components  of  the  Software 

Process  Improvement 
Infrastructure 


Objectives  This  appendix  provides  a  brief  discussion  the  three  princi¬ 

pal  components  of  the  software  process  improvement  (SPI) 
infrastructure.  The  reader  should  become  familiar  with  the 
roles  and  responsibilities  that  are  outlined  for  each  compo¬ 
nent. 

The  identified  roles  and  responsibilities  are  only  a  stenting 
point;  they  can  be  expanded  or  contracted  to  fit  specific  or¬ 
ganizations. 

In  some  instemces  benefit  can  be  gained  from  having  addi¬ 
tional  components  to  the  SPI  infrastructure.  These  compo¬ 
nents  are  described  in  A.4  on  page  179  and  A.5  on 
page  182.  T3rpically,  these  additional  components  are 
formed  in  organizational  environments  that  are  either  veiy 
large  and/or  are  geographically  dispersed. 

Purpose  Executive  management  will  determine  the  size,  scope,  and 

responsibilities  of  the  infrastructiire  to  support  the  SPI 
program.  Taking  into  accotmt  such  things  as  the  organiza¬ 
tion’s  size,  needs,  strategy,  and  culture,  management  will 
determine  the  number  of  layers,  authority,  and  responsibil¬ 
ity  for  each  component  and  who  should  be  represented 
within  the  infrastructure. 

To  build  buy-in  for  the  SPI  program,  the  infi*astructure  is 
created  and  staffed  with  representatives  fi’om  all  parts  of 
the  organization.  Involving  all  parts  of  the  organization 
builds  a  feeling  of  ownership  and  participation  in  the  pro¬ 
gram. 
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An  example  of  an  infrastructure  is  shown  in  Figure  A-1  on 
page  168.  The  first  of  the  three  components  shown  is  a 
management  steering  group  (MSG),  whose  membership  is 
drawn  from  the  organization’s  existing  management  struc¬ 
ture.  Reporting  to  the  MSG  is  the  software  engineering  pro¬ 
cess  group  (SEPG).  The  leader  of  the  SEPG  also  partici¬ 
pates  as  a  non-voting  member  and  sometimes  serves  as  the 
facilitator  for  the  MSG.  Membership  of  the  SEPG  is  drawn 
from  the  practitioners  who  are  working  on  the  projects  in 
the  organization.  Depending  on  the  size  of  the  organiza¬ 
tion,  SEPG  membership  can  be  on  a  full-time,  part-time,  or 
some  combination  of  full-  and  part-time  basis.  In  all  cases 
there  should  be  a  full-time  person  leading  the  SEPG. 

Reporting  to  the  MSG  with  dotted-line  relationship  to  the 
SEPG  are  the  technical  working  groups  (TWGs).  Member¬ 
ship  on  the  TWGs  is  drawn  from  those  areas  of  the  organi¬ 
zation  that  would  be  affected  by  any  recommendations  for 
improvement  change  made  by  the  TWG. 


Figure  A-1 :  Example  of  Infrastructure 

The  components  that  make  up  the  SPI  infrastructure  each 
have  a  specific  role  in  the  SPI  program.  The  infrastructure 
that  is  created  should  be  sized  based  on  the  needs  of  the 
SPI  program.  Care  should  be  taken  that  the  size  and  shape 
of  the  infrastructure  does  not  get  in  the  way  of  the  SPI  pro¬ 
gram.  Each  component  has  a  scope  of  clearly  defined  duties 
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and  responsibilities.  Figure  A-2  below  is  an  expansion  of 
the  infrastructure  to  support  a  SPI  program. 


Figure  A-2:  Expansion  of  Infrastructure  in  Figure  A-1 
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A.1  The  Management  Steering  Group  (MSG) 


A.1  The  Management  Steering  Group  (MSG) 


Purpose  The  MSG  is  made  up  of  the  management  team  that  repre¬ 

sents  the  highest  level  of  management  in  the  organization. 
Its  purpose  is  to  guide  the  SPI  implementation  activities  in 
the  organization.  The  MSG  will  establish  the  goals  and  ob¬ 
jectives  and  set  the  direction  and  priorities  for  the  SPI  pro¬ 
gram.  The  MSG  should  also  apply  improvement  activities 
to  the  existing  management  processes. 

The  MSG  will  supply  the  resources  necessary  to  carry  out 
the  SPI  program.  It  will 

•  charter  TWGs  for  specific  process  improvement 

•  approve  training  to  support  the  SPI  program 

•  determine  the  measurement  and  success  criteria  used 
to  evaluate  the  program 

The  MSG  will  also  serve  to  resolve  issues  that  arise  during 
the  SPI  program  that  cannot  be  handled  by  the  SEPG  and 
TWGs.  The  MSG  removes  barriers  to  the  SPI  program  and 
creates  a  recognition  and  reward  structure  to  recognize  the 
efforts  of  the  people  involved  in  accomplishing  the  process 
improvement. 

The  MSG  is  made  up  of  the  senior  site  manager,  as  chair, 
and  other  members  drawn  from  his  or  her  management 
team.  The  MSG  meets  monthly,  probably  more  frequently 
in  the  early  stages  of  the  SPI  program,  moving  toward  a 
fixed  monthly  schedule.  It  would  be  a  good  practice  to  have 
the  SEPG  leader  be  the  facilitator  for  the  MSG  meetings. 
The  meeting  is  mandatory  for  all  MSG  members  and  oper¬ 
ates  formally  with  agendas,  minutes  and  action  items.  By 
its  actions  the  MSG  can  demonstrate  to  the  organization  its 
commitment  and  support  of  the  SPI  program. 

The  MSG  will  exist  for  the  duration  of  the  SPI  program. 
Members  may  change  as  the  organization  changes  and  ma- 
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tures,  but  the  roles  and  responsibilities  to  the  SPI  program 
will  remain. 

•  Link  SPI  program  to  organization’s  vision  and  mission. 

•  Allocate  resources  and  insure  work  distribution. 

•  Monitor  implementation  results  and  provide  corrective 
actions  as  necessary. 

Activities  that  will  be  performed  by  the  MSG  include  the 
following: 

•  Approve  SPI  strategic  action  plans. 

•  Establish  TWGs. 

•  Draft  TWG  charters. 

•  Draft  tactical  action  plan. 

•  Hold  monthly  meetings  (2-4  hours). 

•  Review  results  of  baselining  activities. 

•  Allocate  resoiirces. 

•  Monitor  working  group  progress. 

•  Approve  broad  installation  of  improvements,  dependent 
on  results  of  pilot  activities. 

•  Report  progress  to  executive  council  (EC). 

•  Facilitate  EC  meetings. 
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The  Software  Engineering  Process  Group 
(SEPG) 


Purpose 


Facilitate  SPI 
Throughout  the 
Organization 


The  SEPG  is  the  focal  point  for  the  organization’s  SPI  pro¬ 
gram.  It  is  responsible  for  and  facilitates  the  activities  that 
relate  to  software  process  improvement,  such  as  action 
planning,  process  improvement,  technology  improvement, 
and  other  activities.  The  SEPG  also  exchanges  information 
between  the  organization’s  SPI  program  and  the  programs 
of  other  SEPGs  across  the  country.  The  SEPG  coordinates 
and  plans  all  of  the  organization’s  SPI  programs.  The 
SEPG  also  leads  the  organization’s  improvement  efforts. 

The  SEPG  maintains  an  organizational  awareness  of  the 
overall  SPI  effort  and  serves  as  a  facilitator  to  insure  the 
successful  completion  of  improvement  activities.  As  the 
catalyst  for  the  SPI  program,  one  of  the  biggest  challenges 
for  the  SEPG  is  to  maintain  the  motivation  and  enthusi¬ 
asm  for  process  improvement  across  and  between  all  levels 
of  the  organization. 

Facilitating  SPI  throughout  the  organization  means  that 
the  SEPG  has  to  obtain  and  maintain  management  support 
for  the  initiative  at  all  levels  and  across  all  functionality. 
The  SEPG  is  assisted  in  accomplishing  this  by  working 
with  the  MSG  to  demonstrate  commitment  to  practitioners 
and  management  of  the  organization. 

The  SEPG  will  facilitate  software  process  assessments  and, 
along  with  the  organization’s  management  and  practitio¬ 
ners,  will  develop  the  SPI  strategic  action  plan  to  guide  the 
efforts.  The  SEPG  will  also  facilitate  other  baselining  activ- 
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Provide  Process 
Consultation 


Track  and  Report 
SPI  Progress 


Serve  as  Focal 
Point  for 
Organizational 
Learning 


Size 


ities  to  provide  definition  for  existing  process  definitions 
and  measurement  activities. 

The  SEPG  supports  the  line  managers  and  development 
projects  by  providing  process  consultation  when  required. 
It  also  works  closely  with  the  line  managers  and  projects  to 
provide  guidance  and  support  when  new  improvement 
changes  are  being  introduced.  It  can  assist  the  line  organi¬ 
zations  in  evaluation  of  new  technology  and  can  also  help 
plan  for  the  introduction  and  transition  to  new  technolo¬ 
gies. 

Another  activity  of  the  SEPG  is  to  monitor  all  of  the  SPI  ac¬ 
tivities  in  the  organization.  The  SEPG  will  report  the  sta¬ 
tus  of  the  various  improvement  activities  that  are  in 
progress  to  the  MSG.  The  SEPG  should  establish  and 
maintain  a  process  database  for  retaining  the  various  arti¬ 
facts  that  result  from  the  improvement  activities.  Tim  ply 
reporting  of  SPI  status  will  allow  the  MSG  to  make  in¬ 
formed  decisions  that  will  support  and  enhance  the  success 
of  the  SPI  program. 

The  SEPG  will  also  serve  as  the  focal  point  of  the  organiza¬ 
tion  s  SPI  activities.  It  will  arrange  for  or  conduct  training 
in  process  improvement  and  continmng  education  in  other 
subjects  relevant  to  the  SPI  program.  From  the  process  da¬ 
tabase,  the  SEPG  will  be  able  to  maintain  and  disseminate 
lessons  learned  as  a  result  of  the  SPI  program. 

The  SEPG  should  be  staffed  at  a  full-time  level  that  is 
equivalent  to  1  -  3%  of  the  organization’s  development  staff. 
In  some  smaller  organizations  (fewer  than  100  profession¬ 
als)  at  least  one  person,  the  SEPG  leader,  should  be  devot¬ 
ed  full  time  to  SEPG  responsibilities.  From  time  to  time, 
the  SEPG  will  need  additional  resources  to  function  effec¬ 
tively. 

These  resources  can  be  “borrowed”  from  the  line  organiza¬ 
tions  on  a  part-time  basis.  Assignments  to  the  SEPG  are 


CMU/SEI-96-HB-001 


173 


A.O 

A.2 


Components  of  the  Software  Process  Improvement  Infrastructure 
The  Software  Engineering  Process  Group  (SEPG) 


Membership 


Objectives 


Tasks 


usually  made  for  a  fixed  period  of  time,  on  the  order  of  one 
to  two  years,  after  which  the  practitioners  return  to  their 
line  organizations  and  their  place  on  the  SEPG  is  filled  by 
another  practitioner. 

Characteristics  of  members  of  the  SEPG  include  experi¬ 
ence  as  a  software  development  practitioner,  sound  knowl¬ 
edge  in  one  or  more  domains,  and  respect  of  their  peers  in 
the  line  organizations. 

The  members  must  support  the  SPI  program,  championing 
it  to  the  rest  of  the  organization.  They  must  also  have  the 
capability  to  effectively  serve  as  agents  of  change  as  new 
and  improved  processes  and  technologies  are  introduced  to 
the  organization. 

SEPG  members  are  critical  to  the  success  of  the  SPI  pro¬ 
gram.  It  would  be  a  good  practice  for  the  MSG  to  set  up  a 
screening  and/or  interview  process  for  SEPG  membership. 
This  would  help  ensure  that  members  have  the  proper 
background,  experience,  and  enthusiasm  for  the  job. 

In  most  organizations  members  of  the  SEPG  are  on  tempo¬ 
rary  assignment  ranging  from  one  to  two  years.  Although 
they  may  return  to  their  regular  jobs,  the  SEPG  continues. 

•  Facilitate  SPI  throughout  the  organization. 

•  Track  and  report  status  of  SPI  programs. 

•  Serve  as  focal  point  for  organizational  learning. 

Some  of  the  tasks  that  are  performed  by  the  SEPG  include 
the  following: 

•  Hold  weekly  meetings. 

•  Identify  and  recommend  improvement  activities  to 
MSG. 

•  Track  and  report  progress  of  improvements  to  MSG. 

•  Determine  effectiveness  of  improvements. 

•  Develop  and  maintain  process  database. 
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•  Develop  training  plans  and  arrange  for  training. 

•  Provide  consultation  to  projects. 

•  Facilitate  CBA  IPIs. 

•  Facilitate  MSG  meetings. 
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A.3  The  Technical  Working  Group  (TWG) 


Purpose  TWGs  are  the  solution  developers  for  the  SPI  program. 

They  are  formed  to  address  a  specific  area  in  the  overall  im¬ 
provement  process.  Their  responsibility  is  to  address  a  spe¬ 
cific  area  for  process  improvement,  and  they  are  given  a 
charter,  resources,  and  authority  to  complete  their  activity. 

The  purpose  of  a  TWG  is  to  improve  the  process  that  it  has 
been  chartered  to  evaluate  and  improve.  The  TWG  is 
formed  by  the  MSG  to  address  a  specific  process  area.  To 
properly  carry  out  its  job,  the  TWG  must  be  given  proper 
guidance  by  the  MSG.  This  is  documented  in  its  charter, 
which  defines  a  clear  mission,  states  the  objectives,  and 
delegates  authority  to  accomplish  the  mission.  Also  implied 
is  a  commitment  of  necessary  resources  and  the  support  of 
management  to  get  the  job  done. 

The  TWGs  can  address  processes  at  any  level  in  the  orga¬ 
nization.  They  can  be  made  up  of  managers,  addressing 
high-level,  cross-functional  processes,  or  they  can  be  made 
up  of  practitioners,  addressing  lower  level,  single-function 
processes.  Key  to  the  membership  of  the  TWG  are  that  the 
members  are  drawn  fi”om  staff  who 

•  are  knowledgeable  about  the  process  being  evaluated 

•  work  in  the  process 

•  would  be  affected  by  changes  made  for  the  improvement 
of  the  process 

The  leader  of  the  TWG  should  be  the  owner  of  the  process 
that  is  being  evaluated.  For  example,  a  TWG  formed  to 
evaluate  and  improve  the  testing  process  would  have  the 
manager  of  testing  as  the  TWG  leader.  Other  members  of 
the  TWG  would  be  selected  to  provide  alternative  perspec¬ 
tives  to  the  process  being  studied.  Having  TWG  members 
who  are  either  customers  of  the  process  or  suppliers  to  the 
process  is  also  beneficial.  If  possible,  the  members  of  the 
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TWG  should  be  volunteers  as  opposed  to  being  assigned  to 
the  team.  This  will  ensure  that  the  team  members  have  an 
expressed  interest  in  the  activity.  Participation  on  a  TWG 
also  provides  for  broadening  of  support  and  additional  buy- 
in  to  the  improvement  activities. 

The  frequency  of  TWG  meetings  varies.  Some  teams  meet 
weekly  for  an  hoim  at  a  fixed  time  and  day.  Other  teams 
may  meet  every  other  Tuesday  for  four  hours.  Regardless 
of  the  frequency,  the  meeting  is  mandatory  for  all  team 
members,  is  very  focused,  and  is  fast  moving.  The  team  fol¬ 
lows  a  formal  agenda,  and  at  the  end  of  the  meeting  time  is 
reserved  to  evaluate  the  meeting.  It  will  take  a  few  meet¬ 
ings  for  the  team  to  get  to  know  and  be  comfortable  with 
each  other  before  they  start  functioning  effectively.  If  pos¬ 
sible,  it  would  be  a  good  idea  for  the  first  one  or  two  meet¬ 
ings  to  be  devoted  to  instruction  on  team  concepts  and 
meeting  effectiveness.) 

•  Document  current  processes. 

•  Assess  current  processes. 

•  Improve  current  processes. 

•  Develop  plan  to  pilot  improved  process. 

•  Pilot  the  new  improved  process. 

Activities  that  are  performed  by  a  TWG  include  the  follow¬ 
ing: 

•  Research  problem  and  identify  solutions. 

•  Formulate  solution. 

•  Revise  tactical  action  plan  to  fit  selected  solution. 

•  Present  possible  solutions  to  MSG  along  with  proposed 
solution. 

•  Select  initial  protot3q)e  group. 

•  Begin  prototjrping. 
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•  Evaluate  results  of  prototype. 

•  Revise  tactical  action  plan  with  lessons  learned  from 
prototype. 
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A.4  The  Software  Process  Improvement  Advisory 

Committee  (SPIAC) 


Purpose  The  purpose  of  the  SPIAC  is  to  support  the  long-range  pro¬ 

cess  improvement  activities  of  the  organization  by  facilitat¬ 
ing  interaction  among  the  organization’s  SEPGs,  promot¬ 
ing  information-sharing  and  providing  a  mechanism  for 
the  SEPGs  to  address  common  problems. 

The  SPIAC  can  be  a  very  valuable  resource  for  those  orga¬ 
nizations  that  have  multiple  SEPGs.  These  SEPGs  may  be 
operating  in  the  same  or  different  geographical  locations. 
The  SPIAC  will  provide  the  organization  a  vehicle  for  shar¬ 
ing  information  about  the  organization’s  SPI  programs. 
Each  member  site  of  the  SPIAC  will  contribute  lessons 
learned  and  reports  of  successful  improvement  activities, 
which  will  benefit  other  SEPGs  in  the  organization.  Much 
valuable  information  can  be  exchanged:  techniques  used 
for  improvement  activities,  technology  evaluations,  vendor 
experiences,  etc. 

The  purpose  of  an  SPIAC  is  to  foster  communication.  Each 
of  the  participating  sites  has  learned  some  valuable  lessons 
as  it  has  progressed.  Having  a  forum  where  these  lessons 
can  be  shared  along  with  successful  improvement  activities 
will  benefit  the  entire  organization.  Member  sites  will  be 
able  to  capitalize  on  work  that  has  already  been  done  at 
other  sites. 

SPIACs  should  meet  quarterly.  At  the  beginning  of  the  SPI 
program,  it  would  be  advantageous  to  meet  more  frequent¬ 
ly  to  resolve  all  of  the  start-up  issues  such  as  charter,  offic¬ 
ers,  length  of  term,  etc.  Meeting  diiration  is  at  least  one  full 
day  as  there  will  be  plenty  of  work  to  accomplish.  Occasion¬ 
ally  the  meeting  may  last  for  two  days. 

Overall  membership  includes  all  members  of  all  of  the  or¬ 
ganization’s  SEPGs,  with  one  voting  member  for  each 
SEPG  represented. 


CMU/SEI-96-HB-001 


179 


A.O  Components  of  the  Software  Process  Improvement  Infrastructure 
A.4  The  Software  Process  Improvement  Advisory  Committee  (SPIAC) 


Meetings  can  be  held  at  different  SEPG  sites  on  a  rotating 
basis.  Thus  the  host  site  and  others  in  close  proximity  may 
have  more  than  one  representative  attend  the  meetings. 
Remote  sites  would  be  represented  by  as  many  SEPG  mem¬ 
bers  that  the  site  could  afford  to  send,  but  at  least  one 
member,  preferably  the  SEPG  leader  should  attend  each 
meeting. 

The  chair  of  the  SPIAC  is  elected  for  a  term  of  one  to  two 
years.  The  chair  is  responsible  for  the  agenda  and  for  coor¬ 
dinating  the  meeting  activities,  schedule,  location,  and  so 
forth.  The  site  hosting  the  meeting  is  usually  responsible 
for  the  local  arrangements,  meeting  minutes,  and  other  ac¬ 
tivities  necessary  to  facilitate  the  meeting. 

Objectives  The  main  objective  of  a  SPIAC  is  to  provide  an  organiza¬ 

tional  forum  for  sharing  information  regarding  the  SPI  ac¬ 
tivities  that  are  being  undertaken  by  different  parts  of  the 
organization.  Additionally,  the  SPIAC  can 

•  advise  management  on  SPI  matters 

•  establish  common  positions  on  critical  SPI  issues 

•  identify  the  benefits  of  SPI  implementations 

•  identify  the  requirements  for  SPI  implementations 

•  maintain  the  process  database  for  items  that  are  suit¬ 
able  for  implementation  across  all  locations 

•  maximize  the  sharing  of  SPI  resources  across  the  orga¬ 
nization 

•  participate  with  external  organizations  and  software 
process  improvement  networks  (SPINs)  for  SPI  pro¬ 
grams 

Tasks  Activities  of  the  SPIAC  include  the  following: 

•  Hold  regularly  scheduled  meetings  (quarterly). 

•  Share  lessons  learned  with  other  SEPGs. 

•  Share  solutions  developed  with  other  SEPGs. 

•  Establish  common  position  on  critical  SPI  issues. 
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•  Advise  management  on  global  SPI  matters. 

•  Identify  benefits  of  SPI  implementations. 

•  Maximize  the  use  of  SPI  resources  across  the  organiza¬ 
tion. 
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A.5  The  Executive  Council  (EC) 


Purpose 


Objectives 


The  EC  is  concerned  with  how  the  overall  improvement  ef¬ 
forts  tie  in  with  the  vision  and  mission  that  the  organiza¬ 
tion  has  set  for  itself.  Typically,  the  EC  reviews  the  SPI  and 
other  process  improvement  efforts  with  knowledge  of  the 
corporation’s  future  directions  and  guides  the  SPI  program 
to  support  that  vision. 

The  EC  wants  to  ensure  that  the  overall  improvement  ef¬ 
forts,  including  SPI,  are  proceeding  in  a  direction  to  sup¬ 
port  the  corporate  vision.  To  support  its  direction  for  the  or¬ 
ganization,  the  council  may  elect  to  communicate  certain 
broad  improvement  strategies  down  the  infrastructure 
chain  of  command  to  guide  the  improvement  efforts.  This 
broad  guidance,  based  on  strategic  opportunities,  becomes 
more  focused  moving  down  the  SPI  infrastructure.  The  di¬ 
visions  or  individual  business  units  can  enhance  and  add 
focus  to  the  guidance  from  the  EC  based  on  the  product  pro¬ 
duced  and  market  opportunities  in  their  business  environ¬ 
ments. 

Membership  on  the  EC  is  kept  very  small.  There  are  no 
more  than  three  to  five  members  who  are  the  organiza¬ 
tion’s  most  senior  management. 

Meetings  should  be  held  semi-annually.  At  the  meetings, 
members  of  the  EC  review  and  discuss  the  progress  of  the 
SPI  programs.  Changes  in  direction  or  focus  should  be  com¬ 
municated  to  the  infrastructure. 

•  Provide  management  oversight  to  a  large  geographical¬ 
ly  dispersed  SPI  initiative. 

•  Monitor  SPI  initiative. 

•  Evaluate  SPI  initiative. 

•  Provide  corrective  actions  as  necessary  to  the  SPI  initia¬ 
tive. 
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Tasks 


Some  of  the  activities  performed  by  an  executive  council  in¬ 
clude  the  following: 

•  Hold  meetings  as  necessary  (semi-annually). 

•  Evaluate  progress  of  SPI  activities  against  defined  cri¬ 
teria. 

•  Review  SPI  activities  against  business  needs. 

•  Institute  corrective  actions  as  necessary. 
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Purpose  A  charter  is  an  important  document  in  a  software  process 

improvement  (SPI)  program.  A  charter  serves  as  an  agree¬ 
ment  or  contract  between  two  parties.  On  one  hand,  the 
charter  makes  explicit  the  authority  and  responsibility  of 
the  entity  being  chartered  and  defines  the  scope  and  mis¬ 
sion.  On  the  other  hand  the  charter  conveys  commitment 
from  and  implied  support  by  the  chartering  entity. 

The  first  part  of  this  appendix  contains  examples  of  actual 
charters  that  are  in  use  by  organizations  that  are  ptu'suing 
software  process  improvement. 

The  second  part  of  the  appendix  contains  templates  that 
can  be  used  in  the  planning  activities.  There  are  templates 
for  a  strategic  action  plan  used  by  the  organization  in  plan¬ 
ning  its  SPI  activities  (page  194),  a  template  for  a  tactical 
action  plan  used  by  TWGs  (page  198),  and  a  template  for  an 
installation  plan  used  to  install  an  improvement 
(page  200). 

It  should  be  remembered  that  these  are  only  samples  and 
suggestions.  What  works  in  some  organizations  may  not 
work  in  others.  Readers  should  tailor  these  instruments  to 
fit  their  organizations. 
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B.1  Management  Steering  Group  Charter 


Generalized  Research  Company  -  Electronics  Group 
Research,  Development,  and  Engineering  Center 
Software  Engineering  Division 
Cooperstown,  New  York 
Management  Steering  Group  (MSG)  Charter 
14  November  1991 


1.  PURPOSE:  The  purpose  of  this  Charter  is  to: 

•  Establish  the  GRC-EG  Software  Engineering  Division  (SED) 
MSG  for  Software  Process  Improvement. 

•  Define  the  mission,  responsibilities,  membership,  and  conduct  of 
operations  for  the  MSG. 

2.  SCOPE:  This  Charter  applies  to  all  organizations  and  personnel, 
including  sub-contract  personnel,  located  at  the  Electronics  Group, 
Cooperstown,  New  York. 

3.  AUTHORITY:  Director,  Software  Engineering 

4.  MISSION:  To  support  the  operation  of  the  Software  Engineering  Process 
Group  and  the  execution  of  the  approved  Action  Plan  for  software  process 
improvement  within  SED.  Utilizing  the  Software  Engineering  Institute 
(SEI)  capability  maturity  model  (CMM)  -based  appraisal  for  internal 
process  improvement  (CBA IPI)  Software  Process  Assessment  (SPA) 
methodology,  SED’s  goals  and  objectives  are  to  identify  key  areas  for 
process  improvement  and  to  propose  a  framework  for  improvement  actions 
consistent  with  the  SED  vision  for  software  process  improvement.  It  will 
also  include  oversight  support  of  Total  Quality  Management  (TQM) 
initiatives. 

5.  MANAGEMENT  STEERING  GROUP  RESPONSIBILITIES: 

•  To  approve  the  establishment  of  Technical  Working  Groups 
(TWGs). 

•  To  approve  and  support  the  membership  of  TWGs. 
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•  To  provide  guidance  to  TWGs  work  in  progress. 

•  To  support  the  implementation  of  approved  recommendations. 

•  To  approve  TWG  initiatives  and  recommendations. 

•  To  terminate  TWGs,  as  appropriate. 

6.  MEMBERSHIP: 

Director,  GRC-SED  (Chair)  Assistant  Director,  GRC-SED 

Director,  Systems  Support  Director,  Operation  and  Engineering 

Manager,  Applications  Development  Manager,  Network  Development 

Manager,  Customer  Support  Center  Manager,  Quality  Assurance 

Manager,  Systems  Software  Development  Manager,  Documentation  Development 

7.  ASSOCIATE  MEMBERSHIP:  Manager,  SEPG 

8.  CONDUCT  OF  OPERATIONS: 

•  The  Management  Steering  Group  will  meet  bi-monthly  or  as 
called  for  by  the  Management  Steering  Group  Chairman. 

•  Meetings  will  have  a  formal  agenda  distributed  at  least  three 
days  prior  to  the  meeting  and  all  meetings  will  be  dociomented. 

9.  TERMINATION:  Not  applicable. 


Daniel  A.  Gibson 

Director,  Software  Engineering  Division 
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General  Research  Company  -  Electronics  Group 
Research,  Development,  and  Engineering  Center 
Software  Engineering  Division 
Cooperstown,  New  York 

Software  Engineering  Process  Group  (SEPG)  Charter 

12  December  1991 

1.  PURPOSE;  The  purpose  of  this  Charter  is  to  authorize  and  approve: 

a.  The  establishment  of  a  Software  Engineering  Process  Group 

b.  Membership 

c.  Conduct  of  operations 

2.  SCOPE:  This  Charter  applies  to  all  organizations  and  personnel  located 
at  the  Electronics  Group,  Software  Engineering  Division,  Cooperstown, 
New  York. 

3.  AUTHORITY;  Director,  Software  Engineering 

4.  MISSION; 

a.  To  manage  the  Electronics  Groups  process  improvement  program. 

b.  To  organize  and  initiate  the  prioritized  actions  in  the  approved 
Electronics  Groups  Action  Plan. 

c.  To  facilitate  and  monitor  the  development  and  implementation  of 
process  improvements. 

d.  To  create  an  atmosphere  to  foster  change. 

5.  RESPONSIBILITIES: 

a.  Oversee  process  improvement  activities  and  report  progress. 

b.  Serve  as  Electronics  Group’s  Change  Agent. 

c.  Lead  Electronics  Group  Software  Process  Assessments  (SPAs). 

d.  Facilitate  action  planning. 
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e.  Oversee  Electronics  Group’s  TQM  Program. 

f.  Facilitate  and  advise  Technical  Working  Groups  (TWGs). 

g.  Provide  for  training  necessary  to  promote  TQM  and  process 
improvement  to  maintain  an  atmosphere  receptive  to  change. 

h.  Serve  as  focal  point  for  coordination  of  Electronics  Group  process 
improvement  activities  with  SEI,  Corporate  headquarters,  and 
sub-contractor  organizations. 

i.  Oversee  activities  of  all  Electronics  Group  SEPGs. 

6.  MEMBERSHIP:  The  Software  Engineering  Process  Group  membership 
consists  of  Core  Members,  and  Review  Members.  Membership  will  be  re¬ 
established  during  the  planning  phase  for  the  next  Electronics  Group  SPA 
effort.  The  identification  and  responsibilities  of  Software  Engineering 
Process  Group  members  are  defined  below: 

a.  Core  Members  will  participate  100  percent  of  their  time  excluding 
leave  and  required  administrative  duties.  The  Core  Members  shall 
perform  the  majority  of  overseeing  implementation  of  the  Action 
Plan  toward  process  improvement.  The  Core  Members  are: 

David  Rimson,  SEPG  Manager 

John  Sibling,  SEPG  Member 

Renee  Doyle,  SEPG  Member 

Barbara  Cott,  SEPG  Member 

Janet  Dempsey,  SEPG  Administrative 

b.  Review  Members  will  contribute  up  to  10  percent  of  their  time.  The 
Review  Members  are  a  representative  group  of  managers  and 
practitioners  who  meet  as  required  to  provide  insight,  additional 
data,  and  consensus  on  the  implementation  of  the  Action  Plan. 
Review  Members  will  also  act  as  a  focal  point  to  identify  experts 
within  their  organization  on  particular  topics.  The  Review 
Members  are: 


Systems  Support,  C.  Royce 

Applications  Development,  T.  Royce/J.  Hasek 

Customer  Support,  R.  Davidson 

Systems  Software,  P.  Thomas 

Operations  &  Engineering,  R.  Fichter,  D.  Jockel 
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Network  Development,  T.  Dzik 
Quality  Assurance,  J.  Potoczniak 
Publications,  M.  Burkitt 

7.  CONDUCT  OF  OPERATIONS: 

a.  The  SEPG  will  report  to  and  receive  guidance  from  the  Assistant 
Director,  Software  Engineering  Division,  Electronics  Group. 

b.  SEPG  will  hold  regular  meetings  as  required. 

c.  The  SEPG  will  keep  the  Division  Director,  Assistant  Director, 
Division  management,  and  Sub-contractor  management  informed 
via  regular  reports  through  the  Assistant  Director. 

d.  The  SEPG  will  facilitate  TWG  Meetings. 

e.  The  SEPG  will  present  periodic  status  reviews  and  conceptual 
briefings  to  the  Management  Steering  Group  (MSG). 

f.  The  SEPG  Chair  will  be  an  associate  member  of  the  MSG. 

8.  EXPECTED  PRODUCTS: 

a.  Documented  processes  and  procedures  on  the  execution  of  the 
Division’s  software  processes 

b.  Status  review  briefings  to  MSG 

c.  TWG  Status  Reports 

d.  Newsletter  input  to  Software  Engineering  News 

e.  Monthly  update  newsletter  on  electronic  mail 

f-  Presentations  to  Division  workforce  on  process  improvement 

g.  Process  improvement  promotional  materials 

h.  Process  improvement  metrics  reports 

9.  MILESTONE  PLAN:  To  be  presented  and  approved  by  the  MSG  at  the 
first  meeting. 

10.  TERMINATION:  The  SEPG  will  function  indefinitely. 

Daniel  A.  Gibson 

Director,  Software  Engineering  Division 
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Software  Process  Improvement  Advisory 
Committee  Charter 


Corporate  Accounting  Services  (CAS) 

Software  Process  Improvement  (SPI) 

Advisory  Committee  (AC) 

Charter 

1.  PURPOSE.  The  purpose  of  the  CAS  SPI  Advisory  Committee  (SPIAC)  is 
to  support  the  long-term  process  improvement  activities  of  the  SEPGs  by 
facilitating  interaction  among  the  CAS  SEPGs  which  will  promote 
information  sharing  and  provide  a  mechanism  for  the  SEPGs  to  address 
common  problems. 

2.  SCOPE.  This  Charter  applies  to  the  membership  of  the  SPIAC  and  joint 
activities  of  the  individual  SEPGs  established  by  CAS.  The  scope  of  this 
charter  is  to: 

a.  Delineate  the  mission  of  the  SPIAC 

b.  Define  the  concept  of  operations 

c.  Define  the  membership 

3.  MISSION. 

a.  Provide  a  forum  for  sharing  of  process  improvement  issues, 
information,  successful  practices,  and  lessons  learned  among  the 
CAS  SEPGs. 

b.  Advise  CAS  management  on  process  improvement  matters. 

c.  Establish  joint  positions  on  critical  software  engineering  process 
improvement  issues. 

d.  Identify  benefits  of  and  requirements  for  process  improvement 
implementation  across  the  SEPGs. 

e.  Maintain  software  engineering  process  definitions,  improvement 
methodologies,  improvement  tools,  and  process  improvement 
metrics  that  are  suitable  for  implementation  across  the 
centers/sites. 
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f.  Maximize  the  sharing  of  available  Software  Engineering  Institute 
(SEI)  and  other  process  improvement  resources  across  CAS  SEPGs 
to  include  coordinating  common  education  on  process 
improvement. 

g.  Participate  with  government  organizations,  industry,  academia, 
and  Software  Process  Improvement  Network  (SPIN)  process 
improvement  efforts. 

4.  CONCEPT  OF  OPERATIONS. 

a.  The  SPIAC  will  conduct  its  activities  in  an  atmosphere  of  non¬ 
attribution. 

b.  The  following  roles  will  be  established  for  the  functioning  of  the 
SPIAC:  facilitator,  member,  scribe,  minute  taker,  time  keeper, 
host,  and  technical  advisor.  The  specific  responsibilities  for  these 
roles  will  be  agreed  to  by  the  SPIAC. 

c.  The  SPIAC  will  meet  quarterly,  and  will  be  scheduled,  if  possible, 
to  coincide  with  the  annual  SEPG  National  Meeting  and  the 
annual  Software  Engineering  Symposium.  SPIAC  meetings  will 
coincide  with  CAS  Directors’  meeting  as  necessary. 

d.  Site  and  agenda  for  each  meeting  will  be  determined  by  mutual 
consent  of  the  SPIAC. 

e.  SPIAC  members  will  execute  tasks  as  agreed  upon  during 
meetings. 

f.  SPIAC  can  recommend  supplemental  PATs/working  groups  for 
software  process  improvement. 

g.  Reports,  recommendations,  and  minutes  will  be  submitted  to  the 
CAS  Directors. 

h.  All  SEPG  members  are  welcome  to  attend  all  meetings.  One  SEPG 
member  will  be  designated  to  represent  each  site,  with  all 
attendees  having  equal  voice  discussions. 

5.  MEMBERSHIP. 

a.  The  recognized  CAS  SEPG  sites  are  as  follows: 

CAS  West,  San  Diego 
CAS  South,  Atlanta 
CAS  East,  Philadelphia 
CAS  International,  New  York 
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b.  Membership  is  open  to  all  SEPG  members  from  these  sites. 

c.  The  Software  Engineering  Institute  is  invited  to  attend  SPIAC 
meetings  in  a  technical  advisory  role. 

6.  REVISION.  This  charter  will  be  reviewed  and  revised  as  deemed 
necessary  by  the  SPIAC  and  its  sponsors. 

7.  TERMINATION.  The  SPIAC  will  function  continuously  until  such  time 
as  it  is  no  longer  needed. 

8.  SPONSORS. 


David  F.  Wilson 
Director,  CAS  West 


William  Johnson 
Director,  CAS  South 


James  W.  Davison 
Director,  CAS  East 


Robert  Smithwell 
Director,  CAS  International 
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Purpose 


Contents 


1.  Overview 


2.  Executive 
Summary 


This  plan  provides  an  introduction  to  the  SPI  program  with 
context  and  background  for  how  the  organization  has  ar¬ 
rived  at  this  point. 

•  It  is  based  on  baseline  Findings  and  Recommendations 
Report. 

•  It  describes  the  motivation  and  direction  for  addressing 
the  findings  within  an  SPI  program. 

•  It  defines  long-range  and  near-term  goals. 

The  suggested  sections  in  the  SPI  strategic  action  plan  are 
identified  in  the  left  column  and  comments  are  in  the  right 
column. 

Provide  context  and  background  on  how  the  organization 
arrived  at  this  point. 

Explain  how  this  action  plan  will  integrate  all  software 
process  improvement  activities  at  this  center. 

•  Explain  how  the  current  improvement  efforts  will  be 
linked  to  recommendations  from  the  assessment  and 
how  those  efforts  and  futiire  efforts  will  be  integrated, 
coordinated,  and  tied  to  the  vision. 

•  Explain  also  that  this  strategic  action  plan  will  provide 
answers  to  the  following  questions:  {Note:  Examine 
these  questions.  If  they  are  not  the  right  ones  for  your 
organization,  change  them.  Make  sure  that  there  are 
sections  within  the  plan  that  address  each  question, 
however.) 

•  What  are  our  goals  for  the  SPI  program? 

•  What  is  our  motivation  to  improve? 

•  What  assumptions  are  we  making? 

•  Who  are  the  players? 

•  How  will  we  measure  successes? 
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3.  Process 
Improvement 
Goals 


4.  Objectives 


5.  Assumptions  and 
Risks 


•  How  will  we  continue  to  improve? 

•  Define  the  long-term  (3-5  years)  and  short-term  (1  year 
or  product  cycle)  goals  for  the  improvement  program. 

•  List  the  strategic  goals  that  have  been  developed  as  a 
result  of  the  assessment  (e.g.,  productivity,  quality, 
risk,  maturity  goals  from  the  action  plan  structure  ma¬ 
terials). 

•  List  the  strategic  goals  that  have  developed  from  the  vi¬ 
sion  or  other  sources.  (Note:  Keep  goals  few,  concise,  un¬ 
ambiguous,  and  measurable.) 

First,  describe  why  this  SPI  progrsun  is  important  and  why 
anyone  should  care  and  want  to  do  anything. 

•  List  the  principal  motivations  (e.g.,  increase 
competitiveness,  avoid  consolidation  or  closure)  that 
will  drive  the  SPI  program. 

•  State  the  objectives  (e.g.,  to  improve  the  quality  and 
productivity  of  the  organization’s  products,  services, 
and  resources)  and  the  consequences  of  maintaining 
status  quo. 

Second,  define  the  guiding  principles  to  be  followed  during 
the  SPI  program  to  achieve  the  goals  and  objectives  (e.g., 
using  the  SPI  program  to  model  higher  maturity  behavior. 
Look  at  the  next  maturity  level  and  determine  how  those 
key  process  areas  can  be  applied  and  used  in  the  SPI  pro¬ 
gram  itself.) 

•  List  critical  assumptions  (e.g.,  sponsorship,  work  load, 
resource  availability)  and  describe  how  each  affects  the 
plan. 

•  Discuss  the  risks  implied  by  these  assumptions. 

•  Identify  the  barriers,  including  the  non-technological 
barriers,  to  the  improvement  program  and  describe  the 
strate^es  to  reduce  those  barriers.  (Note:  If  using  the 
Managing  Technological  Change  implementation  plan, 
tie  it  in  here.) 
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6.  Organization  for 
Process 
Improvement 


7.  Responsibility 
Matrix 


8.  Criteria  for 
Success 


9.  Improvement 
Agenda 


•  Define  and  describe  the  infrastructure  that  is  in  place  or 
being  created  to  support  the  improvement  program. 

•  Describe  the  organizational  entities  (e.g.,  MSG,  SEPG, 
etc.)  created  to  support  process  improvement  in  terms  of 
their  composition,  roles,  responsibilities,  and  interfaces. 
Reference  the  charters  for  these  groups  and  attach 
those  charters  to  Section  9,  Improvement  Agenda. 

•  Identify  the  sponsor  and  what  current  resources  are 
committed.  {Note:  this  is  summarized  from  the  resourc¬ 
es  identified  in  Section  9.) 

•  Describe  which  group  is  responsible  for  what  through¬ 
out  the  SPI  program 

•  List  the  SEPG  coordinating  activities  with  the  MSG  and 
TWGs. 

•  Describe  which  group  is  responsible  for  what  through¬ 
out  the  SPI  program. 

•  Describe  how  the  goals  from  Section  3  (Process  Im¬ 
provement  Goals)  will  be  measured  and  how  the  organi¬ 
zation  will  recognize  success  in  achieving  those  goals. 

•  Describe  how  improvement  activities  will  be  measured 
and  evaluated  at  both  the  organizational  and  project 
levels. 

This  section  provides  the  what  of  the  action  plan.  The  ef¬ 
forts  are  described  at  a  high  level,  resource  requirements 
are  identified,  and  the  relationships  between  each  major 
activity  are  described  so  that  the  reader  can  see  how  these 
different  activities  are  integrated. 

•  Provide  a  high-level  description  of  all  current 
improvement  efforts  in  terms  of  what  they  are  doing, 
what  resources  are  currently  committed  to  the  activity, 
and  what  resources  are  required  to  complete  the 
activity. 

•  Describe  how  the  above  existing  activities  map  to  the 
recommendations  from  the  assessment.  Identify  any 
gaps,  partial  or  otherwise,  between  the  recommenda¬ 
tions  and  the  current  improvement  activities. 
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•  Provide  a  high-level  description  of  all  additional  im¬ 
provement  activities  that  will  be  needed  to  completely 
address  all  of  the  recommendations  and  achieve  the 
goals  and  objectives  of  this  action  plan.  This  description 
should  be  expressed  in  terms  of  what  each  activity  will 
accomplish  and  what  resources  are  required  to  accom¬ 
plish  the  activity. 

•  Define  how  activities  will  be  prioritized  and  what  the 
priority  and  selection  criteria  will  be. 

•  Identify  how  improvement  projects  will  be  selected  to 
participate  in  the  SPI  program. 
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B.5 

Tactical  Action  Plan 

Purpose 

This  plan  identifies  the  activities,  schedules,  and  deliver¬ 
ables  of  a  TWO. 

The  plan  also  discusses  resource  requirements;  interfaces 
and  dependencies  with  other  groups;  assumptions,  risks, 
and  risk  mitigation;  and  schedules  and  milestones. 

•  Specify  the  charter  and  scope  the  effort  of  the  TWG. 

•  Guide  the  TWG  efforts. 

Contents 

The  suggested  sections  in  the  tactical  action  plan  are  iden¬ 
tified  in  the  left  column  and  comments  are  in  the  right  col¬ 
umn. 

1.  Introduction/ 
Overview 

♦  Identify  the  recommendation  that  this  plan  will  sup¬ 
port. 

•  Provide  an  overview  of  what  must  be  accomplished. 

2.  Objectives/ 
Charter 

•  Describe  the  objectives  and  purpose  of  this  working 
group.  (Note:  If  this  information  already  exists  in  the 
form  of  a  charter,  that  document  should  be  appended  to 
the  action  plan.) 

•  Describe  the  scope  of  the  working  group’s  efforts. 

3.  Detailed 
Description 

•  Provide  an  accimate  and  concise  description  of  the  task. 

4.  Resources 

•  Include  a  definition  of  what  the  task  is  and  a  list  of  the 
major  activities  and  artifacts  associated  with  it. 

Describe  resources  required  for  this  task,  including  person¬ 
nel,  money,  computer  resources,  etc.  Also  describe  who  is 
responsible  for  each  task. 
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5.  Interfaces/ 
Dependencies 

6.  Work  Breakdown 
Structure  (WBS) 

7.  Schedule 

8.  Risks 

9.  Status/Monitoring 


Each  working  group  has  an  interface  with  other  groups. 

Define  and  document  these  interfaces  in  this  section. 

Break  the  overall  task  into  small,  manageable  pieces  that 

can  be  used  as  the  basis  for  planning,  identifying  mile¬ 
stones,  reporting,  and  control. 

•  Describe  when  each  of  the  task  elements  described  in 
the  WBS  are  to  be  completed.  Use  Gantt  or  PERT 
charts. 

•  Key  accomplishments  should  be  made  into  milestones 
and  tracked  against  original  estimates. 

Provide  a  basis  for  risk  management  and  contingency  plan¬ 
ning. 

•  Describe  how  status  will  be  reported.  {Note:  Completed 
status  reports  should  be  appended  to  the  tactical  action 
plan  to  maintain  a  history  of  all  activity.) 

•  Discuss  how  progress  will  be  monitored  (comparisons  of 
actual  progress  against  proposed  schedules). 

•  Discuss  how  significant  schedule  deviations  or  changes 
will  be  handled. 
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B.6  Installation  Plan 


Purpose  This  plan  will  define  the  steps  necessary  to  install  an  im¬ 

provement  into  a  sub-unit  of  the  organization.  The  plan 
will  contain  the  objective  and  purpose  of  the  improvement, 
a  WBS  of  the  activities,  schedules,  resource  requirements, 
and  criteria  for  success. 

Contents  The  suggested  sections  in  the  installation  plan  are  identi¬ 

fied  in  the  left  column  and  comments  are  in  the  right  col¬ 
umn. 

1.  Introduction/  .  Identify  the  technology  to  be  installed  that  this  plan  will 

Overview  support. 

•  Provide  an  overview  of  what  must  be  accomplished. 

2.  Goals,  Objectives  Describe  what  will  (should)  be  accomplished,  why  it  is 
and  Purpose  needed,  and  what  kinds  of  projects  or  functional  areas  it 

applies  to.  (Note:  goals  should  be  measurable.) 

3.  Technology  .  Provide  an  accurate  and  concise  description  of  the  tech- 

Description  nology. 

•  Include  a  definition  of  what  the  technology  is  and  a  list 
of  the  major  activities  and  artifacts  associated  with  us¬ 
ing  that  technology. 

4.  Tailoring  .  Provide  guidelines  on  how  and  when  to  tailor  this  tech¬ 

nology  and  this  installation  plan. 

•  Define  the  mandatory  requirements  and  the  optional 
components  or  requirements. 

•  Define  options  in  terms  of  types  of  projects,  types  of 
functional  areas,  etc. 


5.  Education  and  •  Describe  what  training  (formal  or  informal)  and  educa- 
Training  tion  is  (a)  required  and  (b)  desirable  for  installation  and 

use  of  this  technology. 
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6.  Evaluation 
Procedures 


7.  Work  Breakdown 
Structure 


8.  Schedule 


9.  Resources 

10.  Interfaces/ 
Dependencies 

1 1.  Risks 

1 2. Status/Monitoring 


•  Define  where  and  when  this  training  or  education  is 
available,  costs,  lead  times  for  reserving  training  seats, 
the  process  to  be  followed  to  request  the  training,  and 
from  whom  it  is  requested. 

Describe  how  the  project  or  functional  area  will  evaluate 
their  installation  and  use.  How  will  they  know  they  have  it 
right? 

Break  the  installation  into  small,  manageable  pieces  that 
can  be  used  as  the  basis  for  planning,  reporting,  and  con¬ 
trol.  Define  entry  conditions  and  inputs,  task  descriptions, 
validation  criteria,  and  exit  conditions  and  outputs  for  each 
task. 

•  Describe  when  each  of  the  task  elements  described  in 
the  WBS  are  to  be  completed.  Use  Gantt  or  PERT 
charts. 

•  Make  key  accomplishments  into  milestones  and  track 
against  original  estimates. 

Describe  resources  required  for  this  task,  including  person¬ 
nel,  money,  computer  resources,  etc.  Also  describe  who  is 
responsible  for  each  task. 

Each  working  group  has  an  interface  with  other  groups. 
Define  and  document  these  interfaces  in  this  section. 

Provide  a  basis  for  risk  management  and  contingency  plan¬ 
ning. 

•  Describe  how  status  will  be  reported.  (Note:  Completed 
status  reports  should  be  appended  to  the  plan  to  main¬ 
tain  a  history  of  all  activity.) 

•  Discuss  how  progress  will  be  monitored  (comparisons  of 
actual  progress  against  proposed  schedules). 

•  Discuss  how  sigmficant  schedule  deviations  or  changes 
will  be  handled. 
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C.O  Establish  Organization 

Process  Maturity  Baseline 


Purpose  There  are  many  different  ways  to  establish  the  process  ma¬ 

turity  baseline  of  an  organization’s  strengths  and  weak¬ 
nesses.  Organizations  have  used  a  variety  of  assessment 
methods  in  the  past,  and  new  variations  are  constantly  be¬ 
ing  developed.  A  variety  of  baselining  methods  are  needed 
because  of  the  differences  between  organizations:  size,  pre¬ 
vious  baselining  activity,  funds  available,  and  so  on.  Rath¬ 
er  than  describe  just  one  method,  this  appendix  describes  a 
generic  series  of  assessment  activities  based  on  the  Soft¬ 
ware  Engineering  Institute  (SEI)  capability  maturity  mod¬ 
el  (CMM)  -based  appraisal  for  internal  process  improve¬ 
ment  (CBA IPI)  method.  The  intent  is  to  provide  an  under¬ 
standing  of  the  tjqjes  and  kind  of  activities  involved  in 
conducting  a  baseline.  The  software  engineering  process 
group  (SEPG)  should  determine  the  type  of  baseline  it 
wishes  to  conduct  and  get  training  on  that  method. 

Appraisals  that  are  based  on  the  CMM  use  a  set  of  common 
requirements  that  are  described  in  the  CMM  Appraisal 
Framework,  Version  1.0.^  This  document  can  be  used  by 
lead  appraisers  for  training  appraisal  team  members,  by 
appraisal  method  developers  for  developing  CMM-based 
appraisal  methods,  and  by  appraisal  sponsors  to  determine 
if  a  specific  appraisal  method  will  fulfill  their  needs. 

The  organization  process  maturity  baseline  establishes  the 
software  process  maturity  level  of  the  organization  and 
identifies  key  areas  for  process  improvement.  The  SEPG 
usually  plans,  organizes,  and  leads  its  organization’s  as- 
_ _ sessment.  Following  the  baselining  activity,  the  SEPG  for- 

1.  Masters,  Steve;  &  Bothwell,  Carol.  CMM  Appraisal  Framework,  Version  7.0(CMU/SEI-95-TR-001). 

Pittsburgh,  Pa.:  Software  Engineering  Institute,  Carnegie  Mellon  University,  1995. 
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Objectives 


mally  documents  the  results  of  the  baseline  in  a  final  re¬ 
port.  The  baselining  team  typically  consists  of  the  SEPG 
and  other  team  members,  drawn  either  from  outside  the 
assessment  site  or  from  within  the  organization. 

A  key  step  of  a  CMM-based  software  process  improvement 
(SPI)  program  is  identifying  where  the  organization  fits 
relative  to  the  five  levels  of  the  maturity  model.  These  ac¬ 
tivities  identify  a  set  of  key  issues  that,  if  addressed, 
launch  the  organization  on  the  road  to  improvement.  The 
baselining  activity  can  be  considered  successful  if  two  goals 
are  met: 

1.  A  reasonable  set  of  issues  is  identified  and  agreed  upon 
by  all  involved,  and  recommendations  are  developed  to 
move  the  organization  on  the  road  to  improvement. 

2.  The  organization  becomes  excited  and  interested  in 
making  changes  at  all  levels,  from  the  lowest  practitio¬ 
ner  to  the  senior  manager.  This  activity  contains  some 
of  the  most  stressing  moments  for  the  SEPG,  both  inter¬ 
nally  and  in  its  relationship  to  senior  management.  It  is 
this  "cauldron”  that  can  either  forge  the  SEPG  into  a 
high-performing  team  or  can  break  the  team.  The  lat¬ 
ter,  if  it  occurs,  usually  leads  to  dissolution  of  the  soft¬ 
ware  process  improvement  (SPI)  program. 

•  Prepare  the  team  and  organization  for  conducting  the 
baseline. 

•  Gather  information  on  the  organization's  software  pro¬ 
cess  maturity  level,  identify  key  process  issues  facing 
the  organization,  and  start  to  develop  a  set  of  priorities 
for  improvement. 

•  Generate  a  report  detailing  all  results  of  the  baselining 
activity,  including  the  findings  that  were  presented  dur¬ 
ing  the  final  findings  briefing  at  the  end  of  the  on-site 
period  and  recommendations  for  addressing  those  find¬ 
ings. 

•  Increase  involvement  and  commitment  throughout  the 
organization. 

•  Identify  barriers  to  change  within  the  organization. 


204 


CMU/SEI-96-HB-001 


C.O  Establish  Organization  Process  Maturity  Baseline 


•  Continue  team  building  for  the  SEPG. 

Entry  Criteria  •  The  baseline  method  for  software  process  maturity  as¬ 

sessment  has  been  selected. 

•  A  team  has  been  established  and  resources  committed 
to  conduct  the  CBA IPI. 

See  Figure  C-1  below  for  a  pictorial  representation  of  the 
tasks  associated  with  establishing  a  maturity  baseline. 


Figure  C-1:  Establish  Organization  Process  Maturity  Baseline — ^Tasks 
Tasks  The  tasks  are  shown  in  the  table  below. 


Tasks 

Page 

Number 

C.1:  Prepare  for  Baselines 

- - - — _ _ _ 

206 

C.2:  Conduct  Baselines 

209 

C.3:  Develop  Baseline  Findings  and  Recommendations  Report 
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C.1  Prepare  for  Baselines 

Purpose  The  purpose  of  this  activity  is  to  lay  the  groundwork  for  a 

smooth  and  successful  baselining  activity.  A  critical  initial 
activity  is  to  establish  the  scope  of  the  baseline  by  identify¬ 
ing  the  parts  of  the  organization  that  will  be  baselined  and 
identifying  the  depth  or  level  of  coverage  needed  from  the 
baseline.  This  is  usually  followed  by  selecting  a  team  that 
represents  those  parts  of  the  organization  to  be  baselined 
and  training  that  team  in  the  specific  baselining  method 
chosen.  Key  baselining  activity  dates  must  be  negotiated 
and  finalized,  such  as  dates  for 

•  initial  data-gathering  and  analysis 

•  detailed  interviewing  and  definition  of  issues 

•  development  of  recommendations 

•  delivery  of  final  report 

Then  the  participants,  particularly  the  projects  and  func¬ 
tional  area  representatives,  must  be  selected  and  briefed 
on  their  roles  and  activities.  The  rest  of  the  organization  to 
be  baselined  must  understand  what  will  happen  and  how  it 
relates  to  the  SPI  program.  Typically  this  information  is 
conveyed  through  a  series  of  briefings.  Detailed  plans 
should  be  developed  for  all  steps  of  the  pre-baselining  activ¬ 
ity,  baselining  activity,  and  post-baselining  activity  peri¬ 
ods. 

Objectives  .  Get  a  team  trained  in  the  baseline  method  selected. 

•  Determine  the  scope  of  the  baseline  and  select  projects 
and  functional  area  representatives  to  participate  in  the 
baselining  activity. 
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C.1  Prepare  for  Baselines 


Entry  Criteria 
Education/Training 

Communication 


•  Make  the  rest  of  the  organization  to  be  baselined  aware 
of  what  a  baselining  activity  is,  how  it  fits  into  the  over¬ 
all  SPI  program,  and  what  will  happen  in  terms  of  ac¬ 
tivities  and  outputs  during  and  immediately  after  the 
baselining. 

•  Finalize  dates  for  the  key  baselining  activity  events  and 
develop  detailed  plans  and  schedules  for  all  activities. 

•  Prepare  all  logistics,  materials  to  be  used,  files,  tem¬ 
plates,  briefings,  etc.,  and  ensure  that  all  tools,  equip¬ 
ment,  and  materials  are  ready  and  in  place. 

A  team  has  been  established  and  resources  committed  to 
conduct  the  baseline. 

A  training  session  for  an  baselining  team  occurs  during 
this  phase.  The  purpose  is  to  train  a  team  in  the  specific 
mechanics  and  skill  requirements  of  the  selected  baselin¬ 
ing  method  as  well  as  to  provide  any  required  background 
information. 

Two  groups  have  responsibility  for  most  communication  ac¬ 
tivities  dming  this  period:  the  management  steering  group 
(MSG)  and  the  SEPG. 

The  MSG  should  publicly  sponsor  and  support  the  baselin¬ 
ing  activity,  preferably  through  individual  staff  meetings 
and  at  group  briefings. 

The  SEPG  will  conduct  informational  briefings  for  the  or¬ 
ganization  as  a  whole  on  what  the  baseline  is,  how  it  re¬ 
lates  to  the  SPI  program,  and  what  will  be  happening.  This 
is  t3q)ically  done  through  briefings  to  sections  of  the  organi¬ 
zation,  with  most  of  the  people  in  that  section  attending 
along  with  the  section’s  manager. 

The  SEPG  should  also  brief  the  selected  participants  on 
their  roles,  responsibilities,  detailed  schedules,  and  the 
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Exit  Criteria 


Tasks 


overall  baselining  process,  concentrating  on  how  the  partic¬ 
ipants’  information  is  to  be  used. 

All  preparations  are  completed  for  the  assessment.  Invita¬ 
tions  have  been  issued,  functional  area  representatives 
(FARs)  and  project  leaders  are  briefed,  everjdhing  is  sched¬ 
uled  and  ready  to  go,  and  a  complete  dry  run  of  the  process 
has  been  satisfactorily  completed. 

•  Determine  scope  of  the  baseline. 

•  Select  and  train  team  in  the  baselining  method  chosen. 

•  Set  expectations. 

•  Determine  baselining  participants. 

•  Finalize  baseline  dates,  plans,  and  schedules. 

•  Prepare  and  test  logistics  for  the  baselining  activity. 

•  Hold  dry  run  or  team  walk-through  of  the  baselining 
process. 

•  Plan  development  activities  for  the  final  report  and  rec¬ 
ommendations. 
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C.2 

Conduct  Baselines 

Purpose 

The  purpose  of  this  activity  is  to  conduct  the  baseline.  This 
typically  starts  with  an  opening  participants’  briefing  for 
all  baselining  participants,  where  the  events,  objectives, 
and  schedules  are  reviewed.  A  questionnaire  is  filled  out  by 
the  selected  participants,  and  then  the  baselining  team  an¬ 
alyzes  the  responses  to  the  questionnaire.  The  baselining 
team  then  prepares  questions  and  areas  to  probe  further 
for  the  detailed  interviewing  and  issue  definition  period 
and  decides  what  supporting  material  it  will  need  to  exam¬ 
ine.  The  team  finalizes  plans  and  logistics  for  this  follow-up 
period  and  then  begins  it. 

Objectives 

•  Gather  information  on  the  organization’s  software  pro¬ 
cess  maturity  level,  identify  key  process  issues  facing 
the  organization,  and  start  to  develop  priorities  for  im¬ 
provement. 

•  Build  consensus  on  the  issues  facing  the  organization 
and  develop  excitement  and  enthusiasm  for  making 
necessary  changes. 

•  Publicly  report  on  the  issues  facing  the  organization 
and  the  strengths  to  build  upon. 

Entry  Criteria 

All  preparations  are  completed  for  the  baseline.  Invitations 
have  been  issued,  FAKs  and  project  leaders  have  been 
briefed,  and  everything  is  scheduled  and  ready  to  go. 

Communication 

Five  groups  have  responsibility  for  most  communications 
during  this  period:  senior  management,  middle  manage¬ 
ment,  the  baselining  team,  project  leaders,  and  FARs. 

Senior  management  should  publicly  sponsor  and  support 
the  baseline  establishment  process  and  ensure  that  their 
line  managers  support  the  process  as  well,  particularly  by 
allocating  time  for  the  participants.  Senior  management 

CMU/SEI-96-HB-001 

209 

C.O  Establish  Organization  Process  Maturity  Baseline 

C.2  Conduct  Baselines 


also  should  emphasize  that  open  and  honest  responses  are 
desired  and  should  accept  and  acknowledge  the  findings. 

Middle  management  should  support  the  process  and  en¬ 
sure  that  any  of  their  people  who  are  participating  in  the 
baselining  process  are  able  to  be  at  their  assigned  activities 
on  time  and  without  interruptions. 

The  baselining  team  will  be  providing  information  to  the 
participants  on  the  process  and  detailed  schedules.  In  addi¬ 
tion,  they  provide  feedback  to  participants  and  formally 
present  the  results  of  the  baselining  activities  back  to  the 
organization. 

The  project  leaders  will  be  providing  information  about 
their  projects  and  giving  feedback  to  the  baselining  team 
about  completeness,  accuracy,  and  credibility  of  the  find¬ 
ings. 

The  FARs  will  be  providing  their  perspective  on  issues  that 
get  in  the  way  of  accomplishing  their  jobs.  They  will  also 
identify  strengths  and  provide  feedback  to  the  baselining 
team  on  the  completeness  and  accuracy  of  the  findings. 

Exit  Criteria  The  on-site  period  has  been  successfully  completed. 


Tasks 


Brief  baseline  participants. 

Administer  questionnaires  and  gather  responses. 

Analyze  responses  and  determine  questions  to  be  asked 
during  interview  periods  as  well  as  areas  to  probe  in 
more  depth. 

Finalize  plans  and  logistics. 

Finalize  preparation  of  supporting  materials  to  be  used 
during  the  interviewing  period. 

Conduct  detailed  interviews  and  hold  focus  group  dis¬ 
cussions  with  selected  participants. 

Identify  issues  and  rank  them. 
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•  Gather  feedback  on  the  issues  identified  and  refine 
them  as  necessary. 

•  Prepare  and  present  a  briefing  to  the  management  team 
and  the  organization  as  a  whole  on  the  strengths  and  is¬ 
sues  identified  and  their  consequences. 
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C.3  Develop  Baseline  Findings  and 

Recommendations  Report 


Purpose  The  purpose  of  this  activity  is  to  document  the  findings  in 

more  detail  than  was  presented  at  the  conclusion  of  the 
baselining  period,  and  to  develop  recommendations  to  ad¬ 
dress  those  findings. 

Typically  the  recommendations  are  developed  through  a 
series  of  brainstorming  or  focus  group  sessions  held  with 
practitioners,  middle-level,  and  senior-level  managers.  The 
participants  in  each  session  are  asked  to  brainstorm  recom¬ 
mendations  for  each  findings  category.  They  are  then 
asked  to  identify  those  recommendations  that  could  be  sim¬ 
ply  and  easily  implemented  in  a  short  period  of  time.  Vol¬ 
unteers  are  solicited  to  start  working  on  some  of  those  sim¬ 
ple  improvements. 

The  baselining  team  then  consolidates  the  recommenda¬ 
tions  fi'om  all  the  sessions  and  creates  final  categories  and 
descriptions  of  recommendations.  The  findings  and  recom¬ 
mendations  are  combined  into  a  report,  which  is  circulated 
through  the  baselining  team,  the  MSG,  the  SEPG,  and  oth¬ 
er  selected  key  stakeholders  for  review  and  comment.  The 
revised  findings  and  recommendations  are  put  into  a  Final 
Findings  and  Recommendations  Report,  and  this  report  is 
delivered,  along  with  a  briefing,  to  senior  management. 

0bj6CtiV6S  •  Increase  commitment  of  different  levels  of  the  organiza¬ 

tion  by  involving  practitioners  and  middle  and  senior 
management  in  the  process  of  developing  recommenda¬ 
tions. 

•  Develop  recommendations  for  the  organization  to  ad¬ 
dress  the  findings  identified  during  the  baselining  peri¬ 
od. 

•  Identify  simple,  inexpensive  improvements  that  can  be¬ 
gin  immediately,  launch  those  efforts,  and  start  to  track 
them. 
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Entry  Criteria 
Communication 


Exit  Criteria 


•  Submit  a  report  and  briefing  of  the  baselining  team’s 
findings  and  the  composite  organization’s  recommenda¬ 
tions  to  senior  management. 

•  Secure  senior  management  commitment  to  proceed  to 
the  next  phase,  action  planning. 

The  baselining  activity  has  been  successfully  completed. 

Four  groups  have  responsibility  for  most  communications 
during  this  period:  the  MSG,  middle  management,  the 
SEPG,  and  practitioners. 

The  MSG  should  publicly  sponsor  and  support  the  recom¬ 
mendations  process  and  ensure  that  lower  level  managers 
support  the  process  as  well,  particularly  by  allocating  time 
for  the  participants.  Senior  management  also  should  pro¬ 
vide  input  on  recommendations  in  the  senior  management 
brainstorming  session.  Lastly,  senior  management  will 
provide  feedback  and  review  on  the  report. 

Middle  management  should  support  the  process  and  en¬ 
sure  that  people  who  are  participating  are  able  to  be  at 
their  assigned  activities  on  time  and  without  interruptions. 
Middle  managers  should  also  provide  their  inputs  on  rec¬ 
ommendations  during  their  brainstorming  session. 

The  baselining  team  will  be  consolidating  information  on 
recommendations,  generating  details  on  the  findings  and 
consequences,  and  facilitating  the  brainstorming  sessions. 
They  will  consolidate,  distribute,  and  brief  the  report. 

The  practitioners  should  provide  their  inputs  on  recom¬ 
mendations. 

The  baseline  Findings  and  Recommendations  Report  has 
been  delivered  and  briefed  to  senior  management,  and  a 
commitment  has  been  received  to  proceed  to  the  Establish¬ 
ing  phase. 
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Tasks 


Grenerate  first  draft  of  findings  fragments. 

Conduct  recommendations  brainstorming  or  focus 
group  sessions  with  practitioners,  middle  management, 
and  senior  management. 

Cluster,  categorize,  and  merge  recommendations. 

Generate  first  draft  of  recommendations  fragments. 

Distribute,  review,  and  update  first  draft  with  the  MSG 
and  other  selected  stakeholders. 

Develop  briefing. 

Distribute,  review,  and  update  final  draft  report  and 
briefing. 

Deliver  report  and  brief  recommendations. 
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Glossary 


agents 

appraisal  team 


baseline  findings 
and 

recommendations 

report 


A  description  of  the  stages  through  which  software  orga¬ 
nizations  evolve  as  they  define,  implement,  measure,  con¬ 
trol,  and  improve  their  software  processes. 

Respected  organization  members  who  understand  SPI 
and  the  CMM  for  software  and  who  educate  about  SPI  and 
advocate  SPI  in  the  organization. 

Team  that  explores  issues  and  develops  a  SPI  proposal  to 
senior  management. 

Group  in  large  organizations  that  defines  strategy  and  di¬ 
rection  for  the  organization’s  process  improvement  efforts. 

Representative  of  a  specific  software  functional  area  (e.g., 
configuration  management,  testing,  coding,  etc.)  who  con¬ 
tributes  to  a  discussion  group  during  a  software  process 
assessment  (SPA). 

Plan  that  defines  steps  for  installing  an  improvement  in  a 
sub-unit  of  an  organization. 


capability 
maturity  model 
(CMM) 

champions 


discovery  team 

executive  council 

functional  area 

representative 

(FAR) 

installation  plan 


The  SEPG  and  others  responsible  for  coordinating  the 
day-to-day  activities  of  the  SPI  effort. 

A  team  trained  in  the  CMM  and  an  appraisal  method  who 
are  chartered  by  the  SPI  sponsors  to  collect,  analyze,  and 
document  softwjire  process  data  needed  to  meet  appraisal 
objectives. 

Report  describing  the  current  state  in  a  specific  area,  with 
prioritized  recommendations. 
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line  management 


management 
steering  group 
(MSG) 


management 
steering  group 
(MSG)  charter 

middle 

management 


organization 

communication 

plan 

organization 
strategic  plan  for 
software  process 
improvement 
(SPI) 

organization 

vision 

pilot 


pilot  plan 


practitioner 


process 


process  action 
team 


The  first  and  second  level  of  management  in  a  medium  to 
large  organization  whose  focus  is  on  the  day-to-day  activ¬ 
ity  of  the  organization. 

Group  responsible  for  linking  the  SPI  program  to  the  or¬ 
ganization’s  vision  and  mission,  demonstrating  sponsor¬ 
ship,  allocating  resources,  monitoring  progress,  and  pro¬ 
viding  guidance  and  correction. 

Document  that  defines  the  mission  of  an  MSG. 


Those  levels  of  management  between  senior  management 
and  line  management  in  a  medium  to  large  organization 
whose  focus  is  on  short-  to  mid-range  business  activities. 

Plan  for  creating  organization-wide  awareness  and  in¬ 
volvement  with  the  SPI  program. 

Framework  for  SPI  in  the  context  of  the  organization’s 
business. 


A  mental  image  of  what  an  organization  will  be  when  its 
goals  have  been  accomplished. 

Initial  implementation  of  an  improvement,  usually  on  a 
small,  controlled  scale,  before  general  installation. 

Plan  that  defines  the  steps  for  conducting  a  pilot  in  an  or¬ 
ganization. 

A  person  who  is  working  within  the  software  development 
framework. 

The  means  by  which  people,  procedures,  methods,  equip¬ 
ment,  and  tools  are  integrated  to  produce  a  desired  result. 

See  technical  working  group  (TWG). 
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process  database 


rollout  strategy 
and  plan 

senior 

management 


software 
engineering 
process  group 
(SEPG) 

software 
engineering 
process  group 
(SEPG)  charter 

software 

practitioners 

software  process 
improvement 
(SPI)  strategic 
action  plan 


software  process 

improvement 

advisory 

committee 

(SPIAC) 

software  process 
improvement 
network  (SPIN) 

software  process 
improvement 
(SPI)  proposal 


A  repository  of  artifacts  containing  records  of  the  data 
gathered  and  generated  during  the  SPI  process. 

Definition  of  the  strategy  and  plan  for  extending  improve¬ 
ment  to  the  organization. 

The  top  manager  and  his/her  direct  reports  in  a  medium 
to  large  organization.  Senior  management  focus  is  typical¬ 
ly  on  the  longer  range  business  activities. 

Group  chartered  by  management  to  build  and  reinforce 
sponsorship  of  SPI,  nurture  and  sustain  improvement  ac¬ 
tivities,  and  ensure  coordination  of  the  SPI  effort  through¬ 
out  the  organization. 

Document  that  defines  the  mission  of  an  SEPG. 


Technical  professionals  who  develop,  maintain  and  sup¬ 
port  software. 

Plan — ^based  on  the  results  of  the  baselining  efforts,  the 
organization  improvement  goals,  and  the  resources  avail¬ 
able — ^which  provides  guidance  for  the  overall  SPI  pro¬ 
gram  and  addresses  how  the  long-range  organization 
goals  will  be  reached. 

Forum  in  large  or  geographically  dispersed  organizations 
in  which  multiple  SEPGs  share  experiences,  lessons 
learned,  and  improvements  accomplished. 


A  group  of  individuals  banding  together  to  explore  their 
common  interests  related  to  software  process  improve¬ 
ment. 

Proposal  that  provides  information  to  management  that  is 
necessary  to  launch  a  SPI  program. 
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stakeholder 

strategic  business 
plan 

tactical  action 
plan 

target  group 


technical  working 
group  (TWG) 

technical  working 
group  (TWG) 
charter 


Person  who  has  a  specific  interest  and  would  be  affected 
by  decisions  and/or  changes  in  his  or  her  areas  of  interest 

Plan  that  specifies  the  business  mission,  business  goals, 
and  strategy  the  organization  will  pursue  for  achieving 
them. 

Plan  that  specifies  charter,  scope,  and  deliverables  for 
specific  improvement  efforts. 

A  group  on  which  attention  is  focused  with  the  intention 
of  influencing  them  to  change  the  way  they  approach  their 
work. 

Groups  created  to  address  a  particular  focus  of  the  SPI 
program. 

Document  that  defines  the  mission  of  a  TWG. 
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Acting  phase,  see  IDEAL  model,  Acting  phase 
appraisal  team 

education  and  skills  56 
assessments  203-214 

B 

Baldridge  evaluation  60 

Baseline  Findings  and  Recommendations  Report  194, 
212-214 
defined  215 
delivered  to  MSG  57 

see  also  baselines,  findings  and  recommendations 
baselines  53-57 

baselining  team  64-65 
determining  new  or  additional  128 
findings  and  recommendations  69 

reconciling  with  planned  improvement  efforts  87 
“management”  67 
maturity  86,  91 
metrics  91 

metrics  baseline  53,  55 
process  91 

process  description  baseline  53 
process  maturity  baseline  54,  65,  203-214 
purpose  of  55,  63 
recommended  minimum  set  of  53 
results  of  65 
reviewing  145 
use  of  53 
briefing  plan  27 
briefings 
project  118 

business  issues  78-79 
business  plans,  see  plans,  business 

c 

CAF.  see  CMM  Appraisal  Framework 
capability  maturity  model  (CMM)  204 
defined  215 

capability  maturity  model  (CMM)  -based  appraisal  for 
internal  process  improvement  (CBA  IPI)54 
CBA IPI  see  capability  maturity  model  (CMM)  -based 

appraisal  for  internal  process  improvement  (CBA  IPI) 
champions,  see  software  process  improvement  (SPI), 
champions 
change 

resistance  to  14—15 
technological  47-48 
charters  185-193 
infrastructure  32 
initial  84 
MSG 

defined  216 

developing  or  revising  35 
example  of  186-187 
SEPG 
defined  217 
developing  36 


example  of  188-190 
SPIAC  191-193 
TWG91, 198 
defined  218 

CMM  Appraisal  Framework  54,  203 
communication 

facilitating  and  encouraging  40-41, 179 
SEPGs,  between  40,  41,  46,  179 
vehicles  for  39 

communication  plan,  see  organization  communication  plan 

D 

Diagnosing  phase,  see  IDEAL  model,  Diagnosing  phase 
discovery  team  14, 19-20 
defined  11,  215 
education  and  skills  13 
forming  20 
organizing  19 

E 

Establishing  phase,  see  IDEAL  model,  Establishing  phase 
executive  council  (EC)  31, 151,  182-183 
defined  215 
tasks  183 

F 

Final  Findings  and  Recommendations  Report  53 
developing  65 

functional  area  representative  (FAR)  208 
defined  215 

G 

goals 

establishing  24 
general  49-50,  195 
high  level 

establishing  137 
specific  195 

I 

IDEAL  model  2 
Acting  phase  5,  93-126 
process  flow  diagram  of  99 
applying  4-5 
Diagnosing  phase  53-66 
process  flow  diagram  of  58 
Establishing  phase  5,  67-92 
process  flow  diagram  of  71 
Initiating  phase  5, 11-52 
process  flow  diagram  of  17 
Leveraging  phase  5,  127-139 
process  flow  diagram  of  130 
overview  of  1-5 

preparing  for  subsequent  cycles  of  43 
improvements 


italicized  page  number  indicates  that  the  item  appears  in 
a  table  or  figure 
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installing  122-123 

information  sharing,  see  communication 
infrastructure,  see  software  process  improvement  (SPI), 
infrastructure 

Initiating  phase,  see  IDEAL  model,  Initiating  phase 
installation  plan  122,  153,  185 
defined  215 
template  200-201 
ISO  9000  9,  60 
ISO  9001  20 

L 

lessons  learned  42-44,  114,  173,  178,  179 
analyzing  133-134 
deployment  117, 124 
gathering  132 

Leveraging  phase,  see  IDEAL  model.  Leveraging  phase 

M 

Malcolm  Baldridge  evaluation  60 
management  steering  group  (MSG)  149,  170-171 
agreement  to  establish  28 
approval  of  rollout  strategy  and  plan  by  115 
baselines,  use  of  171 
briefing  on  strategy  116 
chair  170 
charter 
defined  216 
example  of  186-187 
choosing  baselines  54 
communication  97 
defined  216 

defining  roles  and  responsibilities  for  85 
education  and  skills  13,  56,  69,  95, 128 
establishing  35 

in  SPI  infrastructure  56,  60,  62,  73, 146, 152 
monitoring  SPI  program  161-163 
objectives  171 

refining  rollout  strategy  and  plan  117 
relationship  to  software  engineering  process  group 
(SEPG)  36 
role  in  SPI  35 

role  in  SPI  strategic  action  plan  67-68 
roles  and  responsibilities  84,  171 
assessments  207 
securing  commitments  96 
staffing  11,  157 

strategic  direction,  providing  164 
tactical  direction,  providing  164-165, 171 
tasks  171 

TWG  lessons  learned  report,  given  to  114 
TWG,  sponsorship  of  91, 168,  171 
management,  line  7,  35,  67,  90,  96, 173 
defined  216 

education  and  skills  13,  69,  95 
management,  middle  19,  67,  96,  209-210,  212-214 
defined  216 

management,  senior  7, 11, 14, 19,  24,  27,  28,  38,  52,  67,  68 
70,  90,  96,  170, 182,  209-210,  212-214 
building  involvement  from  55 
defined  217 
initial  commitment  13 
proposal  to  23 

sponsorship  and  commitment  reaffirmed  by  129 

sponsorship  of  SPI  program  68 

see  also  management  steering  group  (MSG) 

Managing  Technological  Change  47,  80 


implementation  plan  195 
maturity  baseline  203-214 
measurement,  see  metrics 
metrics  98,  105,  106,  107,  159-161,  170,  196,  200 
process  91 

process  metrics  reports  124 
MSG.  see  management  steering  group  (MSG) 

0 

organization  communication  plan  15,  23,  26,  29,  48,  52,  81 
defined  216 

organization  strategic  plan  for  SPI 
defined  216 

organizational  approach 
revising  135 


pilot 

defined  216 
pilot  plan  153 
defined  216 
pilot  solutions  107 
plans 

availability  for  subsequent  SPI  cycles  135 
briefing  27 

business  49,  67,  68,  69,  76-77,  78,  82 
communications  10 

continuing  guidance  to  SPI  program,  developing  127 
deployment  or  rollout  10 
high  level  SPI  11,  24 
installation  122,  153,  185 
defined  215 
template  200-201 

Managing  Technological  Change  implementation  195 
organization  communication  15,  23,  26,  29,  47,  48,  52 
81 

defined  216 

organization  strategic  for  SPI 
defined  216 
defined  10,  216 
pilot,  defined  10 

rollout  strategy  and  95,  111,  115,  118,  124,  153 
defined  217 
refining  117 
tailoring  119 

SPI  strategic  action  9,  11,  51,  153 
approval  of  145,  171 
building  commitment  to  90 
completed  89 
creating  67-70 
developing  53 

developing  new/revised  138 
development  of  172 
“guiding  principles”  section  51 
“improvement  agenda”  section  of  83,  86 
incorporating  baseline  results  into  65 
incorporating  baselines  into  87 
initiating  development  of  55 
motivations  documented  in  81 
“motivations”  section  of  81 
“organization”  section  of  62,  84,  85 
template  194-197 
updating  56 
strategic  73,  153 
strategic  business  155 
defined  218 

tactical  action  10,  91,  92,  97,  104,  153,  171,  177,  178, 
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185 

defined  218 
template  198-199 
tactical  for  TWG  101-102 
templates  194-201 
training  121 
practitioners  11 

building  involvement  from  55 
defined  216 

education  and  skills  13,  56,  69,  95 
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